home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
BBS Toolkit
/
BBS Toolkit.iso
/
rbbs_pc
/
173adoc.zip
/
RBBSDOC2.ASC
< prev
Wrap
Text File
|
1990-08-26
|
358KB
|
6,894 lines
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 12-10
DKAAAA.ZIP is ready for download.
DKAAAAa.ZIP is ready for download.
DKAAAAb.ZIP is read for download.
As each file is downloaded successfully it is removed from the list and is
no longer displayed to the user as ready for download.
12.6.2 The "Library" Subsystem and PC-SIG's CD-ROM
--------------------------------------------------
The CD-ROM published by PC-SIG consists of a DOS subdirectory for each 360K
diskette in the PC-SIG library. Sometimes the disk contains all the files
already in the ARC format other times they just contain a group of files.
The key here is the A)rchive function. The resulting file to be made
available for download will NEVER be greater than 360k. This is important
since a caller may only have a floppy based system and could not capture a
file any larger than a 360k floppy can contain.
The PC-SIG's CD-ROM creates the problem of listing both the individual
files contained on each diskette as well as a summary description of the
individual disks. This can be solved by listing each of the 18,000+ files
in the MASTER.CDR using positions 43-76 for the description, positions 77-
79 for the disk drive, and positions 80-82 for the valid categories for
downloading. These are contained in the file specified by CONFIG parameter
217.
MASTER.CDR might also contain a list of names of the files that would be
created by the A)rchive function. This allows the caller to scan a
category (i.e. category 200) for disk titles only. Note that the files do
not exist until the user uses the A)rchive function. A SysOp who did not
wish to allow individual file downloads might only include these entries in
the MASTER.CDR rather than the other 18,000 entries.
The directory for the PC-SIG CD-ROM is over 1.5 megabytes in length and can
take up to 10 minutes to search completely (when using a PC at 4.77 MHz).
If the SysOp is using FMS, it is recommended that the category file for the
normal FMS directory and the category file for the Library FMS directory be
the same (PC-SIG has 27 different categories for its files).
12.7 Creating the Personal Files Directory
------------------------------------------
RBBS-PC's "personal" file support is analogous to RBBS-PC's support of
"personal" messages in that these files are specially addressed to a
specific caller or group of callers based on security. Personal file
downloads differ from the general download in three major ways:
1) the time limit check is bypassed in personal downloads, meaning that a
qualifying caller can download a file regardless of time left.
2) only files explicitly listed in the personal directory can be
downloaded. Normally files to be downloaded will be looked for on the
disk(s) where files are available for downloading whether they are
listed in a directory or not.
3) only callers with matching user record or sufficient security can
download a file. Normally any caller with security enough to issue
the download command can download a file.
RBBS-PC's FILE MANAGEMENT SUBSYSTEM 12-11
Personal files provide a way that files can be delivered to specific
individuals. As an example, a vendor's support bulletin board for a
software product might make the upgrade downloadable only by paying
customers. A credit reporting corporation can make credit reports
electronically available only to the people who order them. Or, a SysOp
can make a file privately available to only one caller.
One of the most useful applications for personal downloads is to make
certain files available regardless of time remaining. Previously, SysOps
had to increase the security of callers or set artificially high session
limits just to make certain large files available. By putting these file
names in the personal directory and limited by security level, these files
can be made available regardless of how little time is left. For example,
the large files comprising RBBS-PC can be made downloadable to all callers
even though they are limited to 30 minutes.
Access to personal files can be limited in two ways. First, the files can
be downloaded only by callers which have a matching value in their user
record. For example, files can be limited by name (any field in the user
record can be selected). Alternatively files can be limited by security
level, meaning that a file can be downloaded by any person with that
security level or higher. File access based on security level can also be
accomplished using the standard RBBS-PC file security mechanism, but to do
so places the caller's under the standard RBBS-PC constraints of maximum
time per session/day.
Using the "P)ersonal files" command in the files section, a caller is asked
what files the caller wants to download. The only files available to the
caller for downloading are those explicitly listed as belonging to the
caller, unlike the general download command which will look for any named
file on the disk. The caller can ask to List the files available. Callers
will see only those belonging to them.
There is a special option to download all and only the "new" files
specifically addressed to the user by matching a field in the caller's user
record. RBBS-PC keeps track of whether the caller has ever downloaded the
personal file. When listing, new personal files are marked with an "*" in
front of their names (they are "tagged"). Selecting the new files starts a
multi-file download for all and only the personal files the caller has
never successfully downloaded.
Files you want downloaded ONLY through the personal file features of
RBBS-PC should be put in their own subdirectory as specified in CONFIG
parameter 142. If you put the personal files in a download subdirectory
they would be available then to anyone who could name them. RBBS-PC will
search the download areas for a personal file if it is not found in the
subdirectory specified in parameter 142.
Second, in the same place as the personal files themselves, put in a
special personal directory with name specified in CONFIG parameter 143.
This directory is the same format as the general file directories of RBBS-
PC. The format is as follows:
Default Field
Positions Length Description of Field
1 - 12 12 The first 12 characters of an entry have the file name,
with no internal spaces.
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 12-12
13 - 73 Variable The next group of characters can have anything in them.
This will be displayed to the caller who asks for a
listing, along with the file name in the first 12
columns. The length of this group is 21 characters
plus the length of the upload description specified in
CONFIG (40-46, defaults to 40). The default length of
this field is 61 characters.
74 -104 Variable The next group of characters are what is used to
identify the file as "belonging" to the caller and must
match a field in the user record. In CONFIG parameter
43 and parameter 44, the SysOp specifies the position
in the user record to use and how many characters. The
default is to begin in column 1 and use 31 characters
for the caller's name, but any field in the user record
can be used. Optionally, a security can be entered in
this last field to limit the file based on the security
level of the caller. To use security rather than a
match on the user record, simply put a blank as the
first character in the field, followed by the security
level.
105 1 The last character must be an "*" to signify that the
file has never been downloaded or an exclamation point
if ever downloaded.
This personal directory works very much like the File Management System
shared directory, using a field in the user record as the category and
limiting callers to their one category, or limiting the file to the group
of caller's with the minimum required security. The personal directory is
fixed length and read in reverse from bottom to top.
After setting up or modifying the personal directory, you use the CONFIG
utility parameter 187 to check whether the personal directory has the
proper format.
The personal directory can be created by a text editor (i.e. EDLIN) but be
sure to put in the "*" in the last column when creating a new entry so that
the file will be tagged as new. Also be sure to make each entry fixed
length. If the user's identity does not fill out the length of the last
field, be sure to pad the record with blanks out to the full length.
When setting up a personal file directory there are seven configuration
options peculiar to personal files:
CONFIG Description
parameter 43 what part of the user record used to identify files as
parameter 44 belonging to the user (beginning column and length),
parameter 143 the name of the personal directory,
parameter 142 the drive and path where the personal files and personal
directory are stored,
parameter 144 the protocol that must be used downloading,
parameter 147 whether the files downloaded are to be concatenated, and
parameter 188 the CONFIG utility to check the structure of the personal
directory to make sure it is in the properly format.
Parameter 147 and parameter 187 require some explanation of how they might
be used. Limiting the caller to a required protocol to use is not
something one would generally do. But, for special purpose downloads, like
RBBS-PC's FILE MANAGEMENT SUBSYSTEM 12-13
downloading to a printer, one might want to require ASCII, for example.
Or, if all callers are to use the same communications package or only a
particular protocol is efficient, you can specify what callers must use.
Concatenating files means that when multiple files are specified for
downloading, the files are sent continuously in one stream of data rather
than individually as separate files. In effect, the files are physically
combined at the time of downloading. All messages between files are
suppressed - the only messages that appear to the caller are those that
normally occur when the first file transfer starts and when the last file
transfer ends. Concatenation is currently supported only for ASCII
downloads.
An example of a situation that might use this feature of RBBS-PC is a
business that generates short reports for clients. Their clients want to
call in remotely to get time-critical reports and print them right in their
office on pre-formatted paper. Each report is a separate file on RBBS-PC
with all the necessary printer commands already included in each file.
A SysOp might set up RBBS-PC such that the main menu was restructured to
make the P)ersonal files function be P)rint reports to reflect the more
specialized nature of the board. Callers to this board would call in,
identify themselves, and select P)rint reports from the main menu. Callers
could use L)ist to see what is available if they are looking for some
report in particular; just select all new reports; or ask for a particular
report if they must have it immediately.
In the last two cases, RBBS-PC would notify the caller to set up to receive
and press [ENTER] when ready. The pre-formatted reports with embedded
printer control sequences would stream out onto the paper (including
formatting like bold or underline) positioning the text to fit in boxes.
The paper is automatically advanced as needed. When done, RBBS-PC beeps
the user, who then turns the "save to printer" feature off of whatever
communications package is being used.
To set up this application, the personal file options would be configured
to use the caller's id (e.g. account number). The files and directory
would be put in a special subdirectory not shared with anything else. The
CONFIG parameters would be set to specify that caller's must use ASCII
("A") as their protocol and that multi-file downloads will be concatenated.
Another example is that of an electronic job placement service that wanted
to limit non-subscribers to a security level 5 with 10 minutes. However,
they also want non-subscribes to be able to download a file of potential
employment opportunities that may take more than 10 minutes. The following
entries would be put into PRIV.DIR:
JOBSFORU.ARC 282888 07-14-87 List of job opportunities you might want 5
/|\ /|\
12 74
Each record is padded with blanks so that 29 blank characters follow the
security level, followed by an '*'. The '*' is not shown in this
documentation since it is in a column too far to the right.
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 12-14
12.8 Automatically Checking & Converting Uploaded Files
-------------------------------------------------------
Verifying the Integrity of a File
---------------------------------
RBBS-PC's on-going commitment to providing SysOps with the ability to
protect themselves and their callers is reflected in precisely this kind of
feature. When a file is uploaded, RBBS-PC will look for a file called
T<ext>.BAT (where <ext> is the characters that make up the extension of the
uploaded file). RBBS-PC looks for this file on the drive and path
specified in CONFIG parameter 105. If this file exits, RBBS-PC will SHELL
to either:
a.) the program specified in the file (if it only has one line) or
b.) to the .BAT file itself.
In this way a SysOp may install whatever processing is desired after a file
has been uploaded.
If the BAT file contains exactly 1 line, RBBS-PC will shell to the contents
of the bat file, passing on the command line the two parameters:
a.) the name of the file upload (first) and
b.) the name of the file to write the results to (second)
If the BAT file contains more than one line, RBBS-PC will SHELL to the BAT
file itself, passing
a.) the name of the file upload for "[1]" and
b.) the name of the file to write the results to for "[2]"
as the first and second parameters, respectively.
RBBS-PC will consider the upload to have failed and delete the uploaded
file, if the file to which the results are to be written has a length
greater than 2 bytes. The BAT file should either
a.) not write a result file or
b.) leave an empty one if the upload is okay.
If the file that was uploaded is not okay, the external application should
write out some error message more than 2 bytes long.
A typical use for this feature of RBBS-PC is to test the compression of the
uploaded file and pipe the results to a text scanner that looks for an
error string and redirects the output to a file if an error is found. For
example if files that are uploaded with the extension .ZIP were to be
tested, a SysOp might create the file TZIP.BAT
PKUNZIP -T [1] | FGREP "error in a" > [2]
An alternative implementation is:
PKUNZIP -T %1
IF ERRORLEVEL 1 ECHO BAD UPLOAD > %2
SETERROR 0
Under versions of QuickBASIC prior to 4.5, programs that reset the error
level cause illegal function call 5 upon return from the SHELL. Therefore
RBBS-PC's FILE MANAGEMENT SUBSYSTEM 12-15
it is necessary to run a utility to reset the error level back to 0 before
going back to RBBS-PC. This is what the SETERROR.EXE file does.
The recommended procedure is to use PKUNZIP, check errorlevel, and reset
error level to 0. PKUNZIP outs somewhat variable strings when different
errors occur, making a filter based on text more difficult to implement.
Converting Uploads
------------------
RBBS-PC can be configured by the SysOp to cause uploads with extension <u-
ext> to be converted to the default extension <d-ext>. To do this, the
SysOp must put a file named C<u-ext><d-ext>.BAT on the drive and path
specified in CONFIG parameter 105. If the file exists, RBBS-PC will SHELL
to it.
If the SysOp wants all .ARC files uploaded converted to a .ZIP file, create
a file CARCZIP.BAT in the subdirectory specified in CONFIG parameter 105.
To convert .PAK files to .ZIP, create the file CPAKZIP.BAT. Sample
conversion batch files are included on the RBBS-PC distribution diskettes.
12.9 Fast File Search
---------------------
RBBS-PC 17.3 includes an enhanced file-search capability for uploads and
downloads. This enhancement has two advantages:
(a) File searches are much faster. In the case of very slow devices like
a CD-ROM, this can be the difference between sub-second response and
a 45 second response. File searches are now virtually instantaneous.
(b) Files not stored on this system can trigger macros. This allows
requests for files stored elsewhere, either off line on backups, or on
other cooperating systems, to trigger later processing.
The basis for the fast file search is a file, configuration parameter 267,
which is a sorted list of file names available for downloading. The
default name is FIDX.DEF.
The format of this file is:
columns 1-12: file name
columns 13-16: location index (1, 2, 3, ...)
columns 17-18: carriage return line feed.
All data is stored as character data and the file is editable. The file
names must be stored with no internal spaces and a period separating the
prefix from the extension. The list of file names MUST BE SORTED BY FILE
NAME in order for the fast file search to work.
The location index is the record number (line number) of the locator file,
whose default name is LIDX.DEF, and has the following layout:
columns 1-63: location of file
column 64: any character. MAKEFIDX puts in a period.
columns 65-66: carriage return line feed.
This file is all character data and is editable. Essentially, the
location index points to a record in the location file. E.g. if FIDX.DEF
has
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 12-16
RBBS-BAS.ZIP 2
HARPIE.ARC 3
and LIDX.DEF has
C:\DOWN1\
C:\DOWN2\
C:\UP\
Then RBBS-BAS.ZIP is located in directory C:\DOWN2 (2nd record) and
HARPIE.ARC is located in C:\UP (3rd record).
The location field should be a drive/path terminating with a "\" if any
path is given, and file must be filled with blanks through column 63 if the
path is shorter. You must put some character in column 64. Many editors
delete trailing blanks, so you should probably put in a non-blank. A
period is a suitable choice.
RBBS-PC will use a binary search on the first 12 characters in FIDX.DEF.
This binary search can be significantly speeded by provided "tabs" for this
file, indicating the record at which the first file is that begins with the
symbols "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ". This is like the "tabs"
you see on dictionaries, so you can directly turn to the B's, for example.
A tab file has the same prefix as the file name file, except that it adds a
"T". For "FIDX.DEF", the tab file would be "FIDXT.DEF". RBBS-PC will
automatically detect and use a tab file if available. The tab has 72
characters in it. Each 2 bytes represents a binary integer whose value is
the record number in FIDX.DEF where the first file occurs that begins with
the respective symbols above. Thus bytes 3-4 show where files begin with
"1" and bytes 69-70 where files begin with "Y".
Two utilities with source code are provided for setting up the fast file
searches. The source, for compiling under QB 4.5, is included.
MAKEFIDX will create both the file name list (FIDX.DEF) and the location
file (LIDX.DEF), from a list of directories (see MAKEFIDX.CFG) or a list of
file names, or both.
You must next sort FIDX.DEF by file name. A good shareware utility for
this is QSORT (QSORT FIDX.DEF /1:12).
MAKETABS will create a tab file (FIDXT.DEF) from the sorted file list
FIDX.DEF.
A sample batch file for recreating a fast file system is MAKEFFS.BAT. It
uses MAKEFIDX.EXE, QSORT.EXE, MAKETABS.EXE, and configuration file
MAKEFIDX.KG. You need only edit MAKEFIDX.KG to change the filespecs
(/FileSpec=) to match where your files are, and where to write the index
files.
Reconfiguring to Take Maximal Advantage of Fast File Searches
-------------------------------------------------------------
The fast file search is virtually instantaneous on an 8088 with a tab file
for 5000 file entries. The savings on wear and tear on the hard disk can
be very significant as well. And the time it takes to set up the fast
file search is only a few minutes. Most SysOps, therefore, will want to
implement fast file searching, whether or not they have a slow device like
a CD-ROM.
RBBS-PC's FILE MANAGEMENT SUBSYSTEM 12-17
RBBS-PC will first search through the drive/paths specified in config to be
available for downloading, as it always did. Files not found there will
then be searched using the fast file search system. The way the fast file
search works is that a file found in its list is looked for only in the
designated location. Nothing else is searched.
The optimal way to implement fast file searching is to reconfigure the
drive/paths available for downloading down to at most the upload directory,
and let the fast file search handle everything else. That way, files will
be searched first in the upload area, and those not found at first will
then be searched using the fast file search system. Note that every file in
the fast file search list is considered to be available for downloading
whether or not its drive/path is listed in the configuration program as a
downloadable area. Note that you can have separate fast file search
systems available for each sub-board. You can also use the fast file
search for common files and have a separate download area for the
sub-boards. Note that whenever you relocate files, you must re-create the
fast file search system. This is not hard since it takes little time and
can be automated.
Macros with the Fast File Search
--------------------------------
The location file for the FFS (LIDX.DEF) can have in it "M! <macro file>",
where "<macro file>" is the name of a macro, instead of a drive/path.
RBBS-PC will then execute the macro. Thus, you can have special
processing for classes of files, perhaps to
o advise that the upload is not wanted
o tell the caller on what other BBS the file can be found
RBBS-PC will put a "U", "D", or "V" in work variable 1 depending on whether
the file request is to upload, download, or view, so that you can customize
your macro for the situation. This if you want to display a message only
on an upload, you could have UNWANT.IMC with
0
{ON [1]
{==U
{*B
The file {C1{FI{C0 is {C2NOT WANTED{C0 here.
Please do not upload it.
{END
{END ON
RBBS-PC regards the file as not found when a macro is executed. However,
you can inside the macro use the macro command "LO" to set a location that
RBBS-PC will use to look for the file, the same as if the drive/path were
given in LIDX.DEF. Thus, you can use macros for files that really are
present. For example, if RBBS-EXE.ZIP is downloaded, the file is located
in D:\D1, and the entry RBBS-EXE.ZIP in FIDX.DEF is mapped to a record in
LIDX.DEF with the entry "M! C:\RBBS\DWNRBBS.IMC", then the following macro
displays a special message but still causes the file to be found:
0
{ON [1]
{==D
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 12-18
{*B
Congratulations. You are about to download the best BBS!
Call me voice at 703-978-4339 if you need any help.
{END
{LO D:\D1\
{END ON
SETTING UP ".BAT" FILES FOR RBBS-PC 13-1
13. SETTING UP ".BAT" FILES FOR RBBS-PC
---------------------------------------
In order for you to take advantage of all RBBS-PC functions, you must run
RBBS-PC via a .BAT file. When processing events such as DOORS, daily
maintenance and Remote DOS access, RBBS-PC exits to DOS, and expects the
.BAT file that invoked it to handle these events.
13.1 RBBS-PC's Startup Batch File
---------------------------------
The batch file (RBBS.BAT) that comes with RBBS-PC is capable of handling
these events, but in order to make full use of it, you must understand the
commands in it. RBBS-PC stores the name of this batch file in CONFIG
parameter 104. This example assumes you have installed RBBS-PC in the
directory C:\RBBS. Each line in the .BAT file is described below:
COMMAND DESCRIPTION
ECHO OFF This tells DOS not to display each command as it executes.
CLS This clears the screen.
C: This makes sure that when you start RBBS-PC, the default
drive is the one where RBBS-PC resides.
IF %node%. == . SET node=1
You should remove this line from RBBS.BAT, and place it in
the AUTOEXEC.BAT for each node. Of course, change the
number to correspond to the node number in each
AUTOEXEC.BAT. This function makes use of the DOS
"environment variable" concept. From now on, when you see
%node%, substitute the node number.
:START This is a "branch label" which allows RBBS.BAT to recycle
continuously.
CD C:\RBBS This line makes sure that when you start RBBS-PC, the
default subdirectory is the one where RBBS-PC resides.
IF EXIST C:\RBBS\NODE%node%\RBBS%node%TM.DEF ...
DEL C:\RBBS\NODE%node%\RBBS%node%TM.DEF
This command checks for the DAILY EVENT signal file, and
deletes it. This is a "cleanup" command, which makes sure
there are no old signal files on the disk.
IF EXIST C:\RBBS\NODE%node%\RBBS%node%F1.DEF ...
DEL C:\RBBS\NODE%node%\RBBS%node%F1.DEF
This command checks for the SysOp EXIT signal file, and
deletes it. This is a another "cleanup" command.
IF EXIST C:\RBBS\NODE%node%\RCTTY.BAT ...
DEL C:\RBBS\NODE%node%\RCTTY.BAT
This command checks for the DOOR signal file, and deletes
it. This is a another "cleanup" command. The path and
filename of this signal file can be set with CONFIG
parameter 103.
RBBS-PC %1 This command actually runs RBBS-PC. The %1 allows you to
specify options when you use the RBBS.BAT file. For
example, if you enter "RBBS LOCAL", the "LOCAL" is passed to
RBBS-PC, so you can run in local mode.
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 13-2
IF EXIST C:\RBBS\NODE%node%\RBBS%node%F1.DEF GOTO EXIT
This command checks for the SysOp EXIT signal file, and if
found, exits the .BAT file. The SysOp EXIT signal file is
created whenever the SysOp presses F1 at the local console.
IF EXIST C:\RBBS\NODE%node%\RBBS%node%TM.DEF RBBSTIME.BAT
This command checks for the DAILY EVENT signal file, and if
found, runs the .BAT file RBBSTIME.BAT. The daily event can
contain any maintenance you wish to perform on a daily
basis. RBBS-PC will create the DAILY EVENT signal file at a
the time specified in CONFIG parameter 261.
IF EXIST C:\RBBS\NODE%node%\RCTTY.BAT C:\RBBS\NODE%node%\RCTTY.BAT
This command checks for the DOOR signal file, and if found,
executes it. The DOOR signal file is created when a caller
opens a DOOR, or the SysOp requests remote DOS operation.
GOTO START This command restarts RBBS-PC during a "recycle." The only
way to stop RBBS-PC completely is to press F1.
:EXIT This is a "branch label." When RBBS.BAT finds the SysOp
EXIT signal file, it branches here, which ends RBBS-PC and
returns to DOS.
For multi-node use, the command "RBBS-PC %1" must be changed to indicate to
RBBS-PC that you are running multiple nodes. The revised command would be:
RBBS-PC %node% RBBS%node%PC.DEF %1
13.2 The Daily Event .BAT file
------------------------------
CONFIG option 261 allows you to specify a time each day that RBBS-PC will
exit for daily maintenance. The supplied RBBS.BAT file can detect this
event (via the RBBS?TM.DEF signal file) and process a .BAT file. The
contents of the daily event file can contain whatever the SysOp wishes:
Tape backup commands, message packing, file verification or virus checking.
Just make sure that the daily event file re-invokes the RBBS.BAT file when
processing is complete, and RBBS-PC will resume after the maintenance.
THE USE OF RBBS-PC "DOORS" 14-1
14. THE USE OF RBBS-PC "DOORS"
------------------------------
A door is a program contained on the RBBS-PC machine which can be run by an
RBBS-PC caller. This allows the BBS user access to functions other than
those provided by RBBS-PC. After the door terminates, control returns to
RBBS-PC.
The concept of doors can be confusing and complicated, but from RBBS-PC's
perspective, it is simple:
When a caller requests a DOOR, RBBS-PC checks to see if the door
exists. If so, RBBS-PC will create a DOOR signal file and exit.
It is the responsibility of the invoking .BAT file (see section
13) to start the door. RBBS-PC will regain control when the
invoking .BAT file ends.
With this simplicity in mind, we will now explain the complex details of
door processing:
As a potential door installer, you should first become familiar with the
door program, WITHOUT RBBS-PC INVOLVEMENT! Most door programs can also be
run directly from DOS. Make sure the program works, and you understand it
before you expect RBBS-PC to run it.
Once you understand the door program, you must set up the interface to
RBBS-PC. A sample door is included with RBBS-PC. The door (DOORTEST) does
nothing, but it does show you how the interface works.
14.1 A Quick Start to Installing Doors
--------------------------------------
To install the door, follow these steps:
- Create the door batch file, and place it in the default RBBS-PC
directory (DOORTEST.BAT is an example). This batch file should
contain the commands needed to run the door, and then return to DOS).
RBBS-PC will automatically restart after the door.
- If you want maximum control over your door, create an entry in the
DOORS.DEF file (see section 14.3). Without this entry, the door will
still work, but you will be able to control more aspects of the door
interface with this control file
- Edit the MENU5 file (including the graphic and color versions) and
enter the name of your door. The door name must be IN CAPS, and the
first word on a line. The sample DOORTEST can be used as a guide. If
the door name is NOT in all MENU5 files, RBBS-PC will allow the SysOp
to exit the door, but your callers will not be able to use it.
RBBS-PC uses the MENU5 as a security measure. If the door name is not
found in this file, callers are denied access to the door.
14.2 The Major Problems with DOORS
----------------------------------
The hard fact about doors is that most DOS application programs that run
perfectly fine locally will not run correctly for a remote caller. The
general reason for this is that, compared the UNIX and even the old CP/M
microcomputer operating system, DOS has very limited support for access to
a computer from a remote site. The primary general problem is getting the
application to take its input from the communications port rather than the
keyboard and getting the application to write its output to the
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 14-2
communications port rather than the local monitor. In addition, even when
input is redirected to the communications port, some remote keystrokes may
not work, such as the function and arrow keys. Also, creating "full
screen" effects on a remote BBS is difficult, because of the wide variety
of monitors and terminal controller cards. Another general problem is how
to pass information between the BBS software and the program doored to,
such as limiting the amount of time a caller can spend in the door. Most
applications also are programmed to wait indefinitely for input and will
not time out. More seriously, if the caller drops carrier, the door should
terminate and send control back to the BBS software, whereas most
applications will totally ignore the fact that carrier drops. Finally,
many applications let the user issue DOS commands from within them or even
to drop to DOS, which would be an intolerable security risk for a BBS.
The upshot of all of these problems is that most, though not all,
applications that run acceptably as doors on BBS's have been especially
designed to run as a door.
14.2.1 Redirecting I/O
----------------------
The main facility DOS provides in its operating system for redirecting I/O
is the CTTY command. Unfortunately, this only works for applications that
use standard DOS bios calls to do I/O rather than "directly write to the
hardware". Unfortunately, the DOS bios for handling I/O is so slow that
most applications directly write to hardware rather than accept a
performance penalty. When SysOp function 7 is used, RBBS-PC will write
out a door that does nothing but redirect I/O and drop to DOS, then
terminate completely. What typically happens after the drop to DOS is
that the output of an invoked program appears on the local monitor rather
than the remote, so that the remote SysOp calling in sees nothing.
While being limited to programs that use standard DOS callers and print a
"line at a time" on the screen, scrolling prior lines up, CTTY has one
major liability. When the output is redirected from the console to the
communications port, nothing appears on the local monitor, so that the
SysOp "snooping" on the BBS is unable to see what the caller does while
dooring. This program is addressed by a device driver called GATEWAY which
adds local echo to remote sending. It is installed in CONFIG.SYS. For
doors, then simply say "CTTY GATE1" rather than "CTTY COM1". For drop to
dos, simply tell RBBS-PC in configuration parameter 106 what device to use
after specifying you do not want to use CTTY.
CTTY does not work in every environment. For example, it is ignored under
Desqview and does not work properly under TANDY DOS. Also, with DOS it
fails to redirect standard error messages. To solve this problem
STDERR.COM is included as part of the basic RBBS-PC system. This program
was provided by Quarterdeck Systems. If you encounter this problem, run
"STDERR.COM" one time only before you start RBBS-PC, including it in your
AUTOEXEC.BAT file.
An alternative method for redirecting I/O is to use DOS redirection on a
command line. The ">xxx" redirects standard output to device xxx and
"<xxx" redirects standard input to device xxx. So, invoking program
"TEST" as follows
TEST <com1 >com1
should send and receive from communications port 1, if the application
supports DOS redirection.
THE USE OF RBBS-PC "DOORS" 14-3
A shareware product called DOORWAY goes a long way toward getting
applications never written to be a door to at least work remotely. You
simply door to DOORWAY and invoke the intended door through DOORWAY rather
than directly. While not every application will run, it does take care of
most I/O problems. See the documentation of DOORWAY on how to install it.
Programs written explicitly as a door will handle these problems
themselves.
14.2.2 Exchanging Information
-----------------------------
Most applications were never designed to take input from another running
program. This creates a problem for BBS's, which almost always limit the
session time a caller can have, so that the time a caller can spend in a
door likewise should have a upper limit, preferably no more that the
session time remaining that the caller has. One of the main advantages of
applications written to be doors is that they are design to take
information from the BBS. RBBS-PC has for years written out information in
a standardized format, in a text file, for doors to read. This file is
DORINFOn.DEF, where n is the node id (1-9,0,A-Z), written to the same
drive/path as the caller's file, and consists of all text, one piece in
information per line, in the following order:
1. The name of the RBBS-PC system
2. The SysOp's first name
3. The SysOp's last name
4. The communications port being used
5. The baud rate and parity with which the caller logged on, and the
baud rate at which RBBS-PC is connected to the modem
6. The network type (if any) RBBS-PC is running in
7. The caller's first name
8. The caller's last name
9. The city and state the caller is from
10. The caller's graphics preferences
11. The caller's security level
12. The caller's time remaining in the current session
13. Whether fossil driver is used (-1 = yes, 0 = no)
RBBS-PC macros allow any information to be written to a file for a door in
nearly any format desired (see 13.4), as well as put different information
on a command line for the door.
RBBS-PC passes the node id as the first command line argument to the
batch file it invokes (or as specified in the door control file) so that
the DOOR knows which DORINFO file to read. There are external utilities
for converting DORINFO interfaces to other formats, for doors that support
different standards.
14.2.3 Terminating After Carrier Loss
-------------------------------------
Applications not written as doors typically will sit and wait forever for
input. The do not "time out", that is, terminate after a limited time in
which no input is received. After if the carrier is dropped, they do not
detect that the remote caller is "gone" and will sit forever waiting for
input. In effect, a dropped carrier "hangs" the BBS and no further calls
will be processed. Programs written as doors will terminate both for
inactivity and when carrier drops. The solution to this problem is to
install a memory resident program that will reboot the PC if carrier drops.
The public domain program WATCHDOG does this. Simply turn WATCHDOG on in
the first statement in the door batch file, and turn it off as the last
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 14-4
statement. WATCHDOG is not needed, and should not be used, for programs
explicitly written to be doors.
14.2.4 Security
---------------
SysOps should realize that doors greatly increase the security risks
associated with running a BBS. One general problem is that most
applications for personal computers assume that the user is the owner and
has access to everything on the PC. As a matter of convenience, they
often give the user access to many functions, such as deleting files, or
even shelling to DOS. This assumption is simply not true when remote
callers door to the application. Very few programs not designed to be a
door let the SysOp disable such dangerous functions.
14.3 Invoking "DOOR"s Via The External Control File
---------------------------------------------------
In addition to simply invoking "DOOR"s using the standard approach outlined
above, RBBS-PC supports a more sophisticated interface to doors. CONFIG
parameter 109 allows the SysOp to specify the name of this control file,
which is usually DOORS.DEF.
This approach allows each DOOR to be invoked in different ways.
Specifically, the SysOp can tailor the way each "DOOR" is invoked as
follows:
- The minimum security level to invoke each "DOOR" may be different.
- The caller may be required to answer a questionnaire before the "DOOR"
is invoked. This is extremely useful if the "DOOR" is a database
search program and the questionnaire gathers the necessary search
criteria from the caller prior to invoking the "DOOR".
- The "DOOR" may be either SHELLed to (RBBS-PC remains in memory and the
"DOOR" is loaded into free RAM) or EXITed to (RBBS-PC terminates
itself and releases the memory for the "DOOR" to use).
- The "DOOR" may be invoked via a "template" (see section 20.2) and
information passed to the "DOOR". "Templates" are useful when passing
information from a questionnaire to a database search program.
RBBS-PC normally passes the node ID as the first parameter to a
"DOOR". When using a "template" to invoke a "DOOR" the "template"
must include the parameter "[NODE]", if the node ID is to be passed to
the "DOOR".
- A file may be specified for RBBS-PC to display to the caller upon
returning from a "DOOR". This file may be created by the "DOOR" that
was invoked (i.e. the output of the database search and retrieval) or
simply a text file that the SysOp created.
- When returning from each "DOOR", the caller can be required to
re-enter their password as an added security verification.
- The maximum amount of time a caller can spend in each "DOOR" can be
specified. If the amount of time remaining the user has on the system
is greater than the amount of time allowed in the "DOOR", the smaller
of the two times is used.
The format of the door control file is:
THE USE OF RBBS-PC "DOORS" 14-5
1. Name of door - up to 8 characters
2. Minimum security to use door
3. Questionnaire to execute before the door
4. Method to invoke doors - "S" for shelling, else go to .BAT file
5. Template for invoking door - make sure the first word has a file
extension - RBBS-PC will check for existence of the first word as
file.
6. Whether to ask for password on return - Y is yes, anything else
bypasses password check
7. File to display after the door
8. Maximum time allowed in doors - time remaining passed to door is
reduced if max time is less.
Note: RBBS-PC normally passes the node id as the 1st parameter to a door.
If a template is used, RBBS-PC will not automatically add this parameter.
If you want it, you should include "[NODE]" in the template. Special note:
A door must still have a .BAT file in order to be invoked, even if the BAT
file is not used in the template!
Example #1:
MYDOOR,4,C:\RBBS\QUESTION\DOORQ.DEF,D,"MYDOOR.BAT [1] [2]",N,MYDOOR.TXT,
This line tells RBBS-PC:
- The name of the door is "MYDOOR"
- Users with security 4 and above can run this door
- Before starting the door, users are asked the DOORQ.DEF questionnaire
- RBBS-PC should EXIT and run the door (rather than SHELLING)
- The door is started by running MYDOOR.BAT, and two parameters
(presumably set in the questionnaire) are passed to the .BAT.
- The caller does NOT have to enter a password to return to RBBS-PC
- The file "MYDOOR.TXT" is shown to the caller before returning to
RBBS-PC
- No time limit (other than the caller's session time) is placed on this
door.
Example #2:
MYDOOR,10,,S,"MYDOOR.BAT [NODE]",Y,,10
This line tells RBBS-PC:
- The name of the door is "MYDOOR"
- Users with security 10 and above can run this door
- No questionnaire is asked before starting the door
- RBBS-PC should SHELL to the door (rather than EXITING)
- The door is started by running MYDOOR.BAT, and the RBBS-PC node number
is passed to the .BAT.
- The caller DOES have to enter a password to return to RBBS-PC
- No file is shown to the caller before returning to RBBS-PC
- A 10 minute time limit is placed on this door (unless the caller's
session time is less than this).
As with all features, the control file approach to invoking a "DOOR" is
optional. However, even if it is used a "DOOR" can only be invoked by a
caller if a .BAT file exists.
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 14-6
14.4 EXITing or SHELLing to "DOOR"s
-----------------------------------
There are two ways to execute other programs from RBBS-PC:
1) EXITing RBBS-PC and invoking the other program via a .BAT file that
RBBS-PC builds dynamically, or
2) SHELLing to the other program while RBBS-PC remains in memory.
EXITing RBBS-PC allows other BASIC programs to be run as external programs
to RBBS-PC, and allows all of RBBS-PC's features to be active in computers
with only 320K of memory. The "price" that is paid is that upon returning
from the externally called program, RBBS-PC's .EXE file must be reloaded
into memory. Unless a control file is used to invoke "DOOR"s, RBBS-PC
always EXITs to "DOOR"s.
SHELLing prohibits other BASIC programs to be run as external programs to
RBBS-PC, consumes memory because RBBS-PC remains in memory when the other
program is running, and requires 386K of memory (under DOS 3.2) to activate
all of RBBS-PC's features. However, SHELLing does eliminate the need to
reload the RBBS-PC.EXE file each time.
14.5 Resetting The User's Record Via a "DOOR"
---------------------------------------------
WARNING -- this is an extremely powerful feature! It opens up everything
in the user record to modification by the "DOOR". The "door" must also
have knowledge of where fields are in the user record and may cease to work
properly when the user record changes its format. The main application for
this is feature within RBBS-PC if for "DOOR"s that maintain certain SysOp-
defined fields.
For a "DOOR" to reset any part of the user record all a door has to do is
include in DOUTx.DEF file, where x is node number, a line in the format
UR(<start>:<end>),<value>
where:
<start> is the beginning byte in user record,
<end> is the number of bytes to revise, and
<value> is what goes into the specified position in the user's
record.
For example,
UR(63:24),"City,State"
would update the city/state field with the value "City,State", setting 24
bytes in user record to that value (blank fill to right), beginning with
character position 63. The "UR" request only works for data stored in
character format in the user record. RBBS-PC supports a second request in
the form
SL,<sign><value>
where "SL" stands for security level. <sign> can be nothing, plus, or
minus, and means respectively to set the security level to the following
value, or to raise or lower the security by the amount specified. For
example, "SL,6" requests that the security be set to 6 whereas "SL,-2"
means to lower the security by 2.
THE USE OF RBBS-PC "DOORS" 14-7
14.6 A Summary of "DOOR"s
-------------------------
Doors stretch IBM's DOS' capabilities and requires more knowledge than most
other BBS functions. If the preceding discussion of "doors" is a complete
mystery to you, contact a SysOp of an RBBS-PC that is using "doors" and ask
for help. However, if you call a SysOp to learn about "doors" for personal
gain (i.e. you are a consultant or some company's employee being paid to
write a "door") have the courtesy to tell him. Please do not take
advantage of the "user helping user" concept. Anyone who has acquired
specialized knowledge has the right to be remunerated for their efforts if
their knowledge is being used to further commercial purposes and they
request it.
THE SECURITY FEATURES OF RBBS-PC 15-1
15. THE SECURITY FEATURES OF RBBS-PC
------------------------------------
RBBS-PC has always been an open system designed for public use. A SysOp
should always ASSUME that EVERY FILE ON THE PC running RBBS-PC CAN BE
DOWNLOADED AND/OR DESTROYED. However, RBBS-PC has extensive
safeguards that systematically enhance security and privacy. For
example, RBBS-PC has the logic within it's code to prohibit anyone
(including the SysOp) from downloading the RBBS-PC "system" files described
in section 6.2. RBBS-PC can still be run as a wide-open system, but
the SysOp has many additional options to restrain access. These
security options make RBBS-PC much more suitable for private and business
use.
RBBS-PC's security is controlled by three things:
1. the system configuration file (RBBS-PC.DEF),
2. the two external security files for
a. passwords (PASSWRDS), and
b. file downloads (FILESEC), and
3. the users file (USERS) in which each user has an assigned
security level.
The users file is controlled by the SysOp user maintenance function 5
as described in section 16. To change a specific users security level you
select the M>odify option and then the S>ecurity option. This allows you
to set the security level for a user. Users cannot set their own security
levels. Section 15.3 describes how to implement special passwords that
provide special privileges to the groups that issue them. Section 15.4
describes how specific files, groups of files, or even whole disk volumes
can have download security levels associated with them.
15.1 RBBS-PC's Security Features
--------------------------------
Each user has an assigned security level, permitting 65,536 possible
security levels. Each command in RBBS-PC also has a security level
assigned to it. Security assignments are controlled by the SysOp. To use
a command, the caller's security level must be at least as high as the
command's security level.
The SysOp can assign a file or group of files both a security level and a
password. To download a file, a caller must have a security level at least
as high as the file's and be able to give the file's password (if one is
present). All users must pass these security tests, including anyone with
SysOp privileges.
Messages can be assigned a password by their creator. Then only persons who
are able to give that password can read or kill the message. Messages with
password protection will show <PROTECTED> when scanned. Callers have no
way of distinguishing messages to private individuals and to groups except
by how they are addressed. Persons with SysOp privileges can read all
messages. See section 15.2 for an example of group passwords.
Security violations are logged to the CALLERS file. These include
attempting to use functions without sufficient security clearance and
failure to give required passwords.
RBBS-PC's default configuration is that of an "open" system.
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 15-2
RBBS-PC's security system provides the SysOp with several choices on how to
run RBBS-PC. The chief ones are as follows:
1. Change the bulletin board from an open system available to all callers,
to a pre-registered system available only to specified users. To support
this option, there is a function in the SysOps user maintenance option 5 to
ADD users.
2. A SysOp can set up different "classes" of users by assigning different
security levels to different users. Concurrently the SysOp would have to
assign different security levels to different commands. For example, new
callers might be permitted only to leave a comment, read bulletins, and
list files that can be downloaded. Or there might be a group of files
assigned a security level that only members of a special interest group can
download.
3. The SysOp can segregate the functions of the bulletin board into
different groups based on a password. A specific file or group of files
can be downloadable only to those who know the password. Similarly,
messages can be made open to everyone knowing the password but closed to
everyone else. This way there can be semi-private portions of the bulletin
board.
15.2 Examples of Uses for RBBS-PC's Security System
---------------------------------------------------
Some examples of how a SysOp can tailor RBBS-PC using RBBS-PC's extensive
security features follow.
SPECIAL INTEREST GROUPS -- A special interest group (SIG) in a users group
wishes to run a RBBS-PC for both the general public and its own use.
An example would be an authors SIG for persons interested in publishing
books and articles or developing commercial software. A definite need
would exist to be able to address messages to everyone in the SIG without
making them open to every caller. The SIG would establish the convention
to password protect general SIG messages with the password AUTHORONLY,
and to address them to AUTHORS SIG.
Another example would be a bulletin board devoted to the exchange of
software. Allowing persons to use the message subsystem would only
interfere with the primary purpose of the bulletin board. Therefore the
SysOp removes from the menu the functions for leaving and reading messages.
To prevent a person from using the functions to leave or read a message
(even though they are not displayed), the SysOp assigns these functions a
security level higher than a person who logs on normally would be assigned.
Another example of using RBBS-PC's security system would be to set up an
agreed upon temporary password such that when a user logs onto the system
they can issue the password and get longer than normally allowed. If the
time for normal users is 30 minutes, the SysOp can set up the special
password SOFTEXCHANGE, with a maximum time on of 150 minutes instead of the
normal 30. By shifting over to this special password after logging in,
members can get extra time if they need it.
SOFTWARE SUPPORT -- An author of a freeware program offers RBBS-PC support
to all persons who register their copies and send a contribution of, say,
$35 per copy. The registered user can get answers for problems and
download free updates and sample applications. The author wants anyone to
be able to call just to find out about the service. New callers get a
THE SECURITY FEATURES OF RBBS-PC 15-3
security level of 2 automatically assigned to them. This allows them to
use only the message subsystem. The file subsystem is assigned a security
level of 7. Contributors are added by the SysOp with a security level of
7 and a pre-assigned password. Except for SysOp functions, registered
users have free reign in the RBBS-PC.
CLIENT SUPPORT -- A SysOp on a public RBBS-PC also works as a management
consultant. She has several associates who work with her on projects. She
needs to be able to send and receive messages from her associates which the
general public should not see. So they agree on a message password
NOTPUBLIC. To support her different clients she also needs to leave private
files for downloading. To each client she assigns a special downloading
password. To restrict downloading to just that client, file names are put
in the file security file with the appropriate password. Only persons with
the password can then download them.
PRIVILEGED ELECTRONIC MAIL -- A company uses RBBS-PC to help support its
regional offices. Only regional vice-presidents should be able to download
certain management reports. In file security these reports are assigned a
high security level of 9, which only managers get.
15.3 How to Implement the Password File
---------------------------------------
CONFIG allows the SysOp to designate the name of the file containing the
privileged group passwords to RBBS-PC. Since this file is a normal ASCII
file, the SysOp can use any text editor to create and update the file.
Put the information for each password on a single line and separate the
fields with commas. It is important to note that EACH record of the
password must contain ELEVEN parameters (i.e. TEN commas). For the
password file, the format is:
parm1,parm2,parm3,parm4,parm5,parm6,parm7,parm8,parm9,parm10,parm11
where:
parm1 -- password that this line applies to
parm2 -- security level for password. If no password was specified, this
is the user security level this line applies to
parm3 -- maximum time in minutes for a single session
parm4 -- maximum time in minutes per day
parm5 -- number of days in the subscription period
parm6 -- start time, in format HHMM 24 hour style, this line applies to
parm7 -- end time, in format HHMM 24 hour style, this line applies to
The start/end time are limits on all other parameters: meaning that they
apply only during the specified times. Specifying 0 for start/end times
means that this line applies all day.
parm8 -- the type of ratio method to use. This should be one of the
following:
'0' - meaning use the files uploaded to files downloaded ratio
'1' - meaning use the bytes uploaded to bytes downloaded ratio
'2' - meaning use the files per day restriction
'3' - meaning use the bytes per day restriction
NOTE:
FIRST TIME CALLERS MUST UPLOAD AT LEAST ONE FILE (BYTE) BEFORE DOWNLOADING
UNLESS THEY ARE:
EXEMPT FROM THE RATIO REQUIREMENTS,
ARE USING THE DAILY RATIO METHOD, OR
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 15-4
AN INITIAL UPLOAD CREDIT HAS BEEN GRANTED.
THE INITIAL CREDIT FIELD IS IGNORED FOR METHODS 2 AND 3.
parm9 -- the ratio field. A positive integer, such as 15, placed in this
parameter requires that the caller maintain a ratio of a least 1 file (or
byte) uploaded for every 15 files (or bytes) downloaded. The ratio of
uploads to downloads can be cumulative over multiple days or it can be
limited to the current day's activities of the caller.
A 0 tells RBBS-PC to record uploads, but it will not record downloads, nor
will it enforce ratios. This allows the SysOp to have a "free" download
period.
A -1 tells RBBS-PC to record uploads and downloads, but not to enforce
ratios. This allows the SysOp to keep records of each user's transfers,
but it will not stop a user from downloading as much as time allows.
parm10 - the initial credit field. This can be any positive integer
including zero. The use of ratio methods 2 and 3 in conjunction with this
field can restrict the number of files (or bytes) that can be downloaded by
an individual or group of callers per day.
parm11 - the elapsed time (in seconds) that a caller must wait after
logging on before "Time Locked" features will become available. See the
description of CONFIG parameter 155 for a full description of how "Time
Lock" works.
Here are some examples of how the PASSWRDS file might be used:
,5,50,,,0001,0600,,,, Security level 5 gets 50 session minutes
,5,25,,,,,,,, between 00:01 AM and 6 AM, and 25 minutes
otherwise.
,7,50,70,730,,,,,,
Security level 7 has a subscription period of 2 years and a session limit
of 50 minutes, and a daily limit of 70 minutes.
BIGTIME,6,52,,,,,,,,
Temporary password BIGTIME gets 52 minutes per session and a security of 6.
EXTEND,5,120,,9999,,,,,,
Temporary password EXTEND gets 120 minutes for the current session (the
user's elapsed time per day would still remain whatever was set in CONFIG
parameter 8), a temporary security level of 5, and a subscription period of
9,999 days.
,7,128,256,,,,,,,120
Users who log on with a security level of 7 are automatically granted 128
minutes on the system for each session, 256 minutes total for each day
(independent of what was set in parameter 8 of CONFIG), and their
subscription period remains unchanged from whatever it was before, but they
must wait 120 seconds before being able to exit to a "door" or download a
file.
SKIPRATIO,170,120,200,90,0600,1200,0,0,,
THE SECURITY FEATURES OF RBBS-PC 15-5
Temporary password 'SKIPRATIO' grants the caller a security level of 170, a
session limit of 120 minutes, a daily time limit of 200 minutes, a 90 day
subscription period, during the hours of 6AM until noon with no ratio
limits. No downloads are added to the counts for the user. Changing the
last "0" to "-1" would cause the counts to be added but not acted on to
limit downloads.
,140,60,60,365,0001,2400,1,10,,
Users with a security level 140, have a session limit of 60 minutes, a
daily limit of 60 minutes, a one-year subscription, but during any hour of
the day they must maintain a ratio of 1 byte uploaded for every 10 bytes
downloaded. There is no initial upload credit. Therefore, an upload must
take place before a download.
,150,70,,90,,,0,15,2,600
Users with a security level of 150, have a session limit of 70 minutes, a
90 day subscription, must maintain a ratio of 1 file uploaded for every 15
downloaded. An initial credit of 2 files are granted to all new/existing
users. However, they can not exit to a "door" or download a file for the
first 10 minutes (600 seconds) of their session.
,165,90,,120,,,0,30,,
Users with a security level of 165, have a session limit of 90 minutes, a
120 day subscription, must maintain a ratio of 1 file uploaded for every 30
downloaded. No initial upload credit is granted.
,170,120,,365,,,2,10,,
Users with a security level of 170 have a session limit of 120 minutes, a
one-year subscription limitations, but can only download 10 files per day.
,200,360,,730,,,3,250000,,
Users with a security level of 200 have a session limit of 360 minutes, a
two-year subscription, but can only download 250000 bytes per day.
If you are using COPY CON to create this file you "MUST" press F6 followed
by a Ctrl/Z at the end of the last entry prior to pressing carriage return.
15.4 Implementing Security for Download Files
---------------------------------------------
CONFIG allows the SysOp to designate the name of the file containing the
passwords and security levels that can be used to restrict downloads of
specific files, volumes, or files names meeting certain "wildcard"
criteria. This file contains file names with download restrictions in the
format:
<filename>, <security level>,<password>
Note: Each line is a record and ends with carriage-return line-feed. The
only optional field is the password field for a filename. By leaving the
password field empty, no password is assigned to a file. The commas
between the fields are necessary. YOU MUST HAVE TWO COMMAS ON EACH LINE
even if you do not have a password associated with the file.
Some examples would be:
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 15-6
COMMAND.COM, 10,DOS
PAYROLL.DAT, 99,BANKRUPT
CALLGIRL.SEX,,ILLEGAL
\FINANCE\STOCKS,100,
The file COMMAND.COM could not be downloaded unless a user had a security
level equal to or greater than 10 AND could supply the password "DOS". The
file PAYROLL.DAT could not be downloaded unless a user had a security level
equal to or greater than 99 AND could supply the password "BANKRUPT". Any
user could download the file CALLGIRL.SEX if they could supply the
password "ILLEGAL". Any user with a security level of 100 or higher
could download the file STOCKS in the DOS subdirectory FINANCE without
supplying any password.
Additionally "wild-card" characters and drive designators can be used to
protect or restrict certain classes of files (by extension, by drive, etc.)
from being downloaded.
Some examples would be:
A:*.*,8,
E:*.SEC,2,PW1
A*.M*,0,GX3
XY?X.*,9,3XG
All files on drive A would require the users to have a security level of 8
in order for a user to download them. Any user who wanted to download a
file whose extension was ".SEC" and was found to be on drive E would have
to not only have a security level of at least 2 but to also give the
password PW1. The third entry above would require a user who wanted to
download any file on any drive with a prefix that began with "A" and an
extension that began with "M" to have a security level of at least 0 and to
enter the password GX3. Finally, the last entry above would require any
user who wanted to download any file on any drive whose four-letter name
began with "XY" and whose last letter was "X" with any extension to have a
security level of at least 9 and enter the password 3XG.
The wildcards "*" and "?" operate just like they do in DOS with two
exceptions. The "?" requires a character. In DOS the name "HAPPY"
satisfies the file specification "HAPPY?" but it does not in RBBS-PC.
Also, in RBBS-PC, a wildcard applies to an extension only if it occurs
after a period. Thus "xyz*" in DOS finds "xyz.a" but not in RBBS-PC
("xyz*.*" will find it).
To get exceptions to the general rule, just put the exceptions first.
RBBS-PC's file security search stops with the first applicable entry that
it encounters. For example,
1. if you want all files on the B drive to require the user to have a
security level of at least 3,
2. except that files on the B drive with the extension ".SEC" would
require the user to have a security level of at least 6, and,
3. regardless of the disk drive that they were on, any file beginning
with "MES" with an extension of ".SEC" would require the user to have
a security level of at least 12
you would enter the following into the file security file
THE SECURITY FEATURES OF RBBS-PC 15-7
MES*.SEC,12,
B:*.SEC,6,
B:*.*,3
Special Note:RBBS-PC is hard coded so that there are some files that nobody
can download -- not even the SysOp. These are RBBS-PC.DEF, users,
messages, callers, group password, comments, the file security, and backup
files. Similarly the batch files that control RBBS-PC and let the caller
exit to DOS 2 can not be downloaded. The default security file provided
with RBBS-PC is empty.
15.5 Implementing Security for RBBS-PC Commands
-----------------------------------------------
RBBS-PC allows each command to be assigned it's own security level. A user
who wishes to invoke an RBBS-PC command must have at least the same
security level as the command. Let's assume that a SysOp wants to set up
the following classes of users:
Classification of Users Security Level
"Locked Out" Users 0
New Users (first time) 1
Normal Users 2
Users who can "view" a Conference 3
Users who can enter Messages 4
Users who can download files 5
Users who can upload files 6
Users who can Join a Conference 7
Users who can do some SysOp commands (Jr. SysOps) 8
Users who can enter a "door" 9
Users who can enter all SysOp commands (Co-SysOps) 10
The following table illustrates one method of assigning each RBBS-PC
command it's own security level:
Security Level
Subsystem/Command Assigned to Command
Messages Subsystem
A>nswer questionnaire............... 4
B>ulletins.......................... 1
C>omments........................... 1
D>oor subsystem..................... 9
E>enter message..................... 4
F>iles system....................... 1
I>nitial welcome.................... 1
J>oin a conference.................. 7
K>ill messages...................... 4
O>perator page...................... 1
P>ersonal mail...................... 2
R>ead messages...................... 2
S>can messages...................... 1
T>opic of messages.................. 1
U>tilities (more)................... 1
V>iew conference mail............... 3
W>ho's on other nodes................3
@>Library Sub-System.................1
Files Subsystem
D>ownload........................... 5
G>oodbye............................ 0
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 15-8
L>ist file directories.............. 4
N>ew files.......................... 5
P>ersonal downloads................. 5
S>earch directories for string ..... 1
U>pload a file...................... 1
V>erbose listing of ARC file........ 1
Utilities Subsystem
B>aud rate.......................... 1
C>lock (time of day)................ 1
E>cho selection..................... 1
F>ile transfer protocol............. 1
G>raphics........................... 1
L>ength of page..................... 1
M>essage Margin..................... 1
P>assword change.................... 1
R>eview preferences................. 0
S>tatistics of system............... 1
T>oggle (line feeds, etc.).......... 1
U>serlog............................ 2
Library Subsystem
A>rchive a Library disk..............5
C>hange a Library disk...............5
D>ownload........................... 5
G>oodbye............................ 0
L>ist file directories.............. 4
S>earch directories for string ..... 1
V>erbose listing of ARC file........ 1
GLOBAL commands
?>What can be done.................. 1
H>elp with a command................ 1
Q>uit to another subsystem or exit.. 1
X>Expert/novice toggle.............. 1
SYSOP Subsystem
1>List comments..................... 8
2>List callers log..................10
3>Recover a Message................. 8
4>Erase comments.................... 9
5>USERS maintenance.................10
6>Toggle page bell.................. 8
7>Exit to DOS 2.x or above.......... 9
15.6 Beware of the "Trojan Horse!"
----------------------------------
Despite RBBS-PC's security always remember that you should always assume:
"EVERY FILE ON THE PC RUNNING RBBS-PC CAN
BE DOWNLOADED, MODIFIED, AND/OR DESTROYED!"
RBBS-PC's security system appears to be so fool-proof that some individuals
have resorted to uploading programs that appear to do one thing, but
actually do something else. These "trojan horse" programs search all the
disks that are connected to the PC that the program is running on for such
RBBS-PC files as RBBS-PC.DEF or USERS. The program then copies these files
to an innocuously named file that can be downloaded later when the person
who uploaded it logs onto the system again. Since RBBS-PC.DEF contains the
pseudonym that the SysOp can use to logon on remotely as the SysOp, once
the user downloads a copy of it the user can then log on as the SysOp and
do just about anything including exiting to DOS and formatting all the
disks on the system. Similarly, the USERS file contains passwords and the
THE SECURITY FEATURES OF RBBS-PC 15-9
security levels of everyone on your RBBS-PC -- some of whom may have SysOp
privileges.
You can protect yourself against anyone logging on as you, the SysOp, by
not allowing anyone to logon as the SysOp remotely (see CONFIG parameter
121). You can protect yourself against unauthorized access of the USERS
file by simply not allowing any user to have SysOp privileges.
Of course there is the "trojan horse" program that doesn't even bother with
the above, but simply destroys all the disk files on all the disks that are
connected to the PC that is running the program.
SYSOP FUNCTIONS 16-1
16. SYSOP FUNCTIONS
-------------------
The SysOp functions are separated into two groups: Those functions that the
SysOp, or user with sufficient security, can use while logged onto the
RBBS-PC, and those functions that are available from the local console.
16.1 SYSOP Commands Within RBBS-PC
----------------------------------
The following operations can be performed by the SysOp, or any user with
sufficient security, at the main RBBS-PC command prompt:
1 - Type COMMENTS file. The contents of the COMMENTS file is displayed.
If commets are saved as PRIVATE MESSAGES, the only time comments will
appear in this file is when the message file is full.
2 - Type CALLERS file. A log is maintained of all persons who have called
the system. This function will list the file showing the users name
and the date and time signed on as well as a log of their activity.
This function is also available through the UTIL menu (function U).
3 - Resurrect a message. This function will restore a message that has
been killed. If the message file has been "packed", the killed
messages are no longer recoverable. The function will ask for the
message number of the message to be recovered.
4 - Erase the COMMENTS file. This function will erase the comments. A
new comments file will be created the next time a user leaves a
comment.
5 - USERS file maintenance. The users file contains entries for each user
registered with the system. This function permits the SysOp to:
A)dd -- add a user to the USERS file.
L)st -- list the USERS file.
P)rt -- print the USERS file on the printer.
M)od -- modify a record in the USERS file.
S)can - scan each record in the USERS file for a particular string.
In <M>odify mode, limited editing of the users record in the USERS file can
be done. The following subfunctions are available:
D - Delete the user.
F - Find another user in the USERS file.
M - Return to the option 5 function prompt.
N - Give the user a new password.
P - Toggle the printer flag to print entries on the printer.
Q - Quit and return to the main message prompt.
R - Reset the user's graphic mode.
S - Set the security level of the user. This can be used to lockout
or grant special privileges to the user.
X - Modify user's upload/download counts.
# - locate any record number within the USERS file.
$ - Change the user's Registration date.
In <M>odify mode a record will be displayed followed by a subfunction
prompt for action. To get to a specific record the record number can be
entered at the prompt and if valid that record will be displayed. If the
record number is invalid or [ENTER] is pressed, the next record in the file
will be displayed.
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 16-2
6 - Toggles the operator page bell on/off. This overrides the "office
hours" specified in the RBBS-PC.DEF file.
7 - SysOp drop to DOS as a remote user. If the SysOp has logged on
remotely and is running RBBS-PC under DOS 2.0 or greater, this
function will use the door interface to create a "remote DOS shell."
RBBS-PC must be able to process door exit .BAT files in order for this
to work (see section 13). The SysOp will then see the DOS prompt at
the remote terminal and can execute whatever DOS commands or programs
the CTTY command supports. DOS will look for COMMAND.COM to be
present on the disk drive you specified in parameter 105. SysOp
function 7, unlike "doors," loads in a copy of COMMAND.COM to run
under the copy that was running RBBS-PC. Also be sure to read
Appendix T and make sure that you THOROUGHLY understands the
limitations that DOS places on you when this option is invoked.
Two areas of caution are advised when using SysOp function 7 under DOS 2.0
or above. First, each SysOp should test what can be done remotely.
Software that reads and writes directly to the video BIOS and does other
things that bypass the standard input and output of DOS simply won't
function correctly. Second, you should be aware that you are in DOS and
can return to RBBS-PC only by issuing the EXIT command. This will return
to the batch file that was built dynamically by RBBS-PC. This file will
then continue executing and is designed to reassign the keyboard as the
console and then re-invoke RBBS-PC. If you get disconnected while in DOS,
your system will be locked up. The console will be assigned to your
communication port and your modem will have dropped the line and will have
been set not to auto-answer. The only way to restore the system is a
manual power off/on sequence.
16.2 SysOp Use of Function Keys and Numeric Pad
-----------------------------------------------
The following function keys are available at the local console, while
RBBS-PC is waiting for a call, or while a caller is online. If RBBS-PC is
operated in LOCAL mode (COM0), RBBS-PC will not allow a non-SysOp user to
access privileged local commands (i.e. a local user cannot raise his
security level with the + key).
F1 - Return to DOS. This is only active when RBBS-PC is waiting for a
call. When the SysOp presses F1, RBBS-PC takes the modem "off hook",
so incoming calls will get a busy signal. It then creates a file in
the same directory as the CALLERS file named RBBSxF1.DEF ("x" is the
node ID). RBBS-PC then returns to DOS. The invoking batch file
should check for the presence of the RBBSxF1.DEF file and halt if it
is present after running RBBS-PC.
F2 - SHELL to DOS. RBBS-PC remains resident but suspended in memory, the
user (if any) remains on-line and the local SysOp is in DOS until the
EXIT command is issued, which returns control back to RBBS-PC and the
caller.
F3 - Printer toggle on/off. This changes the printer on-line status. When
on-line, the printer will print each caller's name and the filenames
uploaded/downloaded. It will also print all unexpected error
messages. This function should only be turned ON when a printer is
attached to the RBBS-PC computer and is ready to print.
F4 - Operator page toggle. This changes the status of "operator annoy"
(i.e. allows the SysOp to be pageable). Operator page time limits are
SYSOP FUNCTIONS 16-3
set by CONFIG parameter 7. This toggle will override the SysOp's
"office hours."
F5 - Tells RBBS-PC to answer the phone and check for an incoming carrier
immediately.
F6- SysOp available. This changes the status of operator available
setting. This is useful if during your "office hours" you temporarily
don't wish to be disturbed.
F7- SysOp NEXT. After the current caller logs off, RBBS-PC will initiate
a local SysOp login.
F8 - Allows the SysOp to grant an on-line user temporary SysOp privileges.
This is a toggle on/off switch.
F9 - SNOOP toggle. This key switches SysOp SNOOP on/off. When SNOOP is
OFF, the local screen will clear. When SNOOP is ON, the local screen
will be updated to reflect what the RBBS-PC user is seeing.
F10- This is the forced chat switch. It announces your presence to the
caller and then allows both you and the caller to type and see each
other's words. The ESC key is used to exit Forced chat mode or to
answer an "O>perator page" request. The F10 key will not function
until a user logging on has reached the Main Menu.
END- Informs the current caller that the SysOp needs the system, then
updates his user record and politely logs him off.
CTRL END
- Logs off and locks out the current user that is on and informs the
user that their presence is unacceptable.
PgUp Displays information about the current user. This information is only
displayed on the local screen. The user's screen is unaffected.
PgDn Clear the local screen (used to remove information displayed via the
PgUp key).
LEFT ARROW
- Subtracts one minute from the user's current session time. Ctrl-Left
Arrow subtracts five minutes from the user's current session time.
RIGHT ARROW
- Adds one minute to the user's current session time. Ctrl-Right Arrow
adds five minutes to the user's current session time.
UP ARROW
- allows the local SysOp to increment an on-line users security level by
one. CTRL-up-arrow or CTRL-PgUp will increase the security by 5.
DOWN ARROW
- allows the local SysOp to decrement an on-line users security level by
one. CTRL-down-arrow or CTRL-PgDn will decrease the security by 5.
The SysOp can also enter commands on the command prompt line while a caller
is on-line. The command entered will cause the system to respond just as
it would if the caller had entered the command. This should be used with
caution because it could confuse a new system user -- users are often timid
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 16-4
enough without knowing that big brother is actually watching them! Let
callers page you and then tell them that you can assist with commands if
they get into trouble.
16.3 Local Status Display
-------------------------
RBBS-PC maintains a status display on the bottom line of the local display.
The items in the display are in the following form:
Node ? AP! PG! AVL ANY LPT SYS 999 NAME CITY, STATE UM UU UB UD
Where:
Node ? is the node number
AP! Indicates this user triggered an AutoPage (see section
7.11).
PG! This caller paged the SysOp.
AVL The SysOp is AVAILABLE
ANY The SysOp ANNOY switch is on
LPT The PRINTER LOG is active
SYS The SysOp wants a LOCAL log-in next
999 The caller's security level
NAME The Caller's name
CITY, STATE The Caller's City and State
UM The MESSAGE file lock (UM=unlocked, LM=locked)
UU The USER file lock (UU=unlocked, LU=locked)
UB The USER BLOCK lock (UB=unlocked, LB=locked)
UD The upload dir/comment lock (UD=unlocked, LD=locked).
MESSAGE AREAS WITHIN RBBS-PC 17-1
17. MESSAGE AREAS WITHIN RBBS-PC
--------------------------------
RBBS-PC is intended to be an open system. As such it can have an unlimited
number of message areas and messages. At the very minimum, RBBS-PC has a
single
1) message area, a file named MESSAGES,
2) user file, a file named USERS, and
3) definition file, a file named RBBS-PC.DEF
In addition to this, additional messages areas can be created as either
"conferences" (i.e. areas that use the same RBBS-PC.DEF file as the main
RBBS-PC message area) or "sub-boards" (i.e. areas that have their own .DEF
file).
17.1 "Conferences" and "Sub-boards" -- the Differences
------------------------------------------------------
A "conference" or "sub-board" can be:
1) "public" -- any caller can join.
2) "public with a separate user file" -- any caller can join and RBBS-PC
remembers the last message read by each caller and will notify a
caller on logon that new mail is waiting.
3) "semi-public" -- only callers with security levels equal to or greater
than that specified for the conference can join.
4) "semi-public with a separate user file" -- only callers with security
levels equal to or greater than that specified for the conference can
join and RBBS-PC remembers the last message read by each caller and
mail waiting.
5) "private with a separate user file" -- only callers who have been
pre-registered in the separate user file for the conference can join
and RBBS-PC remembers the last message read and mail waiting.
A "sub-board" is just a conference that also has a configuration definition
file (.DEF). Sub-boards can be public, private, or semi-private. Access
to a sub-board is controlled by the configuration parameter 123 which sets
the minimum security level required to enter the "sub-board." A
"sub-board" configuration file has the same format as the RBBS-PC main
configuration file, and is created and edited using CONFIG.EXE. This
allows a "sub-board" to have its own unique welcome file, commands,
security levels, menus, help, bulletins, directories, and up and download
areas. "Sub-boards" can share as much or as little as desired with other
conferences or other "sub-boards" within the same RBBS-PC system. The only
things a "sub-board" cannot change are the primary MESSAGES file and the
communications parameters used by the RBBS-PC it is running under.
To the caller, a "sub-board" appears just like another bulletin board,
accessed from a bulletin board rather than through a telephone number.
Public sub-boards, just like public boards, are those whose minimum
security to join is not higher than the default security for new users.
"Sub-boards" basically allow a single telephone number to offer very
different types and levels of services. Independent "sub-boards" run under
the same RBBS-PC service radically different types of terminals/PC's.
Within the same RBBS-PC, one "sub-board" may have 80 column menus for IBM
and compatible PC callers, another may have 40 column menus for Atari and
Commodore PC users, and still another may have 20 column menus for those
using telecommunications devices for the deaf (TDD's). No longer is it
necessary to provide three independent telephone numbers for three such
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 17-2
different services. All callers can dial the same number and simply switch
over to the appropriate board. Extra lines can be added to a roll-over and
service all the boards. "Sub-boards" make it much easier and feasible for
a SysOp to market bulletin board services by allowing hardware to resources
to be pooled under one software "umbrella" such as RBBS-PC and yet service
a very diverse set of requirements -- much the same way that Compuserve
does. One of the best hardware configurations for running a multi-board
service like this is PC-Slaves, because adding additional boards are
extremely easy, with virtually no system degradation.
"Sub-boards" greatly benefit "umbrella" organizations. For example, a
computer club that covers IBM computers, Apple, Atari, and Commodore. No
longer does software intended for one type of computer have to get mixed in
with listings for another computer. Each computer can have not only
separate messages, but bulletins and directories as well.
"Sub-boards" make it easy to have different "levels" of service based on
security level. Many SysOps run both a "free" and a "subscription" board.
The most typical arrangement for this is to have the free board be on the
bottom of a telephone roll-over and the pay board be on the top, and for
the top board to require a higher security level. Non-subscribers who call
the pay board number get "kicked" off the board. "Sub-boards" on the same
telephone line would give both paying and non-paying callers equal access,
if desired. Another example is that callers with enhanced security can
join a sub-board to get access to even more downloads. Or, executive
officers for an organization can have access to a "sub-board" that has not
only special messages but special bulletins and files.
The naming conventions of the files associated with a "conference" or "sub-
board", for example called CLONES, would be:
CLONESM.DEF --- the message file
CLONESU.DEF --- the user file
CLONESW.DEF --- the "welcome" file (for conferences only)
CLONESC.DEF --- the configuration file (for "sub-boards" only)
Using the configuration .DEF file associated with a "sub-board" allows each
SysOp to make the "sub-boards" as unique or similar as desired. Two
security levels are very important. The minimum security to log on to the
board determines who can join the "sub-board". And the default security
level is what newly added callers are assigned.
A "sub-board", like any conference (public, semi-private, or private) is
closed to all who have insufficient security. To make a "sub-board"
completely private, simply set the minimum CONFIG parameter 123 (the
minimum security level a new user needs to logon) to be higher than any
normal caller would have. The only way for callers to be able to join a
completely private "sub-board", like a private conference is for the SysOp
to have added them previously to the users file associated with that "sub-
board".
The security level a caller gets when auto-added is the default security
level for the "sub-board" and not the current security level of the caller.
This is to prevent special privileges that a caller has in one "sub-board"
from automatically propagating into other "sub-boards". For example, a
caller with SysOp privileges in one "sub-board" who joins another does not
become receive SysOp privileges in the other.
MESSAGE AREAS WITHIN RBBS-PC 17-3
The security level used to determine what "sub-boards" a caller can join is
not the current security level but the original security level the caller
had on the main board.
RBBS-PC detects if the bulletins in the "sub-board" are the same as in the
main RBBS-PC system and does not re-display them when a "sub-board" is
joined.
"Sub-boards", public conferences, semi-private conferences, and private
conferences can all co-exist within the same RBBS-PC system. Sub-boards in
turn can have sub-boards in them, as well as public, semi-private, and
private conferences.
The primary disadvantage of "conferences" or "sub-boards" that have
separate user files associated with them is the additional disk space that
is required for the users file. RBBS-PC's CONFIG parameter 290 allows the
SysOp to let a user on as a "guest" if there is no more room left in the
users file for the "sub-board", semi-private conference, or private
conference. Not having a user record defeats one of the main mechanisms
for remembering a user's preferences, of course, but the SysOp can start
with a smaller users file and expand later without the risk of denying
callers access.
Obviously, "sub-boards" take more time to set up and maintain. While it is
nice to be able to have parts of RBBS-PC vary radically from one another,
every one that does vary is another item to create and maintain. "Sub-
boards" can multiply the work necessary, for example, to maintain
bulletins. There are more users and message files to oversee. However,
Kim Wells MU-EDIT is an invaluable tool for managing multiple message and
user files. Give Kim's RBBS-PC call at (301) 599-7651/7652 and get a copy
of MU-EDIT.
17.2 Making a "Conference" or "Sub-board" Successful
----------------------------------------------------
To make a "conference" or "sub-board" successful several guidelines should
be followed rather rigorously:
1) Establish a "conference" or "sub-board" chairman (i.e. a SysOp) to
manage the conference. The SysOp's job is to add new users, delete old
ones, make sure that the subject and/or the agenda of the conference
is adhered to by killing messages that are inappropriate. This is
best accomplished by having a separate user file for each "conference"
or "sub-board" in which the caller only has SysOp privileges when in
the specific "conference" or "sub-board."
2) Establish an "agenda" or list of subject areas for the "conference" or
"sub-board." One of these should be about new subject areas. These
areas should be VERY narrow in scope. The essence of any good
conference is keeping it focused. Everyone has been in at least one
meeting/conference that was a waste of time because whoever was
running the meeting/conference did not keep the dialogue centered on
the subject or agenda.
3) If a continuity of dialogue is to be achieved, it is advisable to keep
the conference "focused" -- either by keeping the number of conference
members limited, or by keeping the subject matter very narrow.
Another interesting thing about "private" conferences and sub-boards
as implemented within RBBS-PC is that they are not "public" and,
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 17-4
therefore, are even more protected by the first, fourth, and fifth
amendments.
17.3 Setting Up a "Conference" or "Sub-board"
---------------------------------------------
The SysOp sets up a "conference" using the CONFIG utility parameter 167 to
pre-format up to two files -- one for the messages to be associated with
the conference and one for the users to be associated with a conference.
The name of a "conference" can be from one to seven characters that are
valid for a file name. RBBS-PC will add "M" (for the messages file
associated the conference) or a "U" (for the users file associated with the
conference) to the filename. The SysOp can then enter the conference
member's names in the conference USERS file by using the SysOp function 5.
The SysOp can "join" any conference and need not be in any particular
conference's USERS file.
Like "conferences", RBBS-PC supports an unlimited number of "sub-boards".
"Sub-boards" are equally easy to create. If CLONES were the name of a
public conference (the CLONES message file CLONESM.DEF exists), all that
would have to be done to make CLONES a "sub-board" would be to run CONFIG
to
1) create a separate user's file, CLONESU.DEF, for this formerly public
conference (if didn't already have a users file),
2) create a "sub-board" configuration file for the CLONES "sub-board"
(a file whose name would be ATARIC.DEF).
The easiest way to make a "sub-board" configuration file is to use the DOS
copy command, starting with another configuration file as a model (e.g. the
one for the main board). To continue with the CLONES example you would
issue the DOS command:
COPY RBBS-PC.DEF CLONESC.DEF
Then invoke CONFIG.EXE to edit that file, using the form
CONFIG CLONESC.DEF
WARNING!! When you create a .DEF file by copying another one as a model,
be sure to run CONFIG against this new file and change the message and user
file names! Otherwise your sub-board will share the user file with another
message base. Here change the message file name to CLONESM.DEF and the
user file name to CLONESU.DEF. The users file name can be anything for a
"sub-board" but the extension .DEF is a good idea because RBBS-PC's
security system will not let any file with that extension be downloaded.
Remember, you do not want to allow callers to download any users file! You
get an extra layer of protection if you put the message, user, and
configuration files in an area not available for downloading.
17.4 Conference File Locations
------------------------------
The files that make up a conference or a sub-board can be placed in several
locations. Especially on multi-node BBSs, care must be taken when locating
conference files.
If a sub-board CONFIG files exists, it must either be in the RBBS-PC
default directory, or in the directory where the MAIN message file is
located. NOTE: If a caller joins a sub-board from within another sub-
board, the MAIN message file location would be the location of the first
MESSAGE AREAS WITHIN RBBS-PC 17-5
sub-board. Once a sub-board CONFIG file is found, all other file locations
will be set by the CONFIG file parameters.
If there is no CONFIG file, RBBS-PC will next look for a MESSAGE file.
First, the subdirectory where the current MAIN message file is located will
be searched, and then the directory where the conference description file
is located (see CONFIG parameter 74) will be searched.
To find the USER file, RBBS-PC first looks where the current MAIN user file
is located, and then in the RBBS-PC default directory.
This may seem complex, and for most SysOps, placing all CONFIG, MESSAGE and
USER files in the default subdirectory is adequate. CONFIG will create,
and locate conference and sub-board files properly when parameter 167 is
slected.
17.5 Establishing a "Conference" or "Sub-board" SysOp
-----------------------------------------------------
RBBS-PC has one of the more flexible and powerful systems for supporting
"assistant SysOps" or "conference moderators". A moderator need not be
made a full SysOp, and whatever security a moderator has, does not transfer
to the rest of the board. Moderators need the following basic functions:
1) read and kill all messages,
2) add and modify users, and
3) forward mail to a better person to answer it.
The ability to do user edits is controlled by the security specified by
SysOp function 5. Incidentally, moderators cannot edit user records with
security higher than theirs. The ability to read and kill all messages is
controlled by a security level specified in CONFIG. RBBS-PC supports
having separate user files for every message area, so that moderator
privileges in one area do not necessarily transfer to others.
To set up a conference or sub-board moderator, the SysOp need only
1) "Join" the conference or sub-board.
2) Use SysOp function 5 to enter the name of the user who is to be the
conference chairperson into the conference's USERS file.
3) Set that users security level in the conference's USERS file to a
security level that can issue the SysOp function 5. This will allow
the conference chairman to add users.
4) Set the minimum security to read and kill all messages to the level of
the moderator.
5) Set the minimum security to change the minimum security to read a
message to the security level of the moderator. This will allow the
moderator to forward everyone's mail.
Any registered user can join a "public" conference or sub-board. When
someone issues the J)oin command to join a conference or sub-board, their
standard security level is temporarily superseded by the security level
associated with their user name within that conference's or sub-board's
USERS file if it is a "private" conference.
For example, a normal user might be given the security required to add
users to a particular conference or sub-board USERS file since they are the
SysOp of that message area. When a user joins the conference or sub-board
of which they are chairman, their normal security is bumped up so that they
can add users to the USERS file of that particular message area. When the
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 17-6
same user exits that message area, their security level is returned to
normal. If they should subsequently join another message area where they
are not chairman, they would be unable to add users to that message area's
USERS file. Other than a message area's SysOp, none of the message area
members should be given any higher security than they otherwise enjoy as a
regular RBBS-PC user.
CALLERS AUTOMATIC NOTIFICATIONS OF MAIL WAITING 18-1
18. CALLERS AUTOMATIC NOTIFICATIONS OF MAIL WAITING
---------------------------------------------------
RBBS-PC has the ability to notify callers about mail waiting for them when
they log on. Callers can be notified for any pair of user/message files
(a) how many new messages were left, and
(b) whether any new messages are to them personally.
RBBS-PC can be configured such that the messages individually reported by
number to the caller when the caller logs on are all messages (i.e. both
old and new, or just new messages since the caller last logged on, or
no messages at all via CONFIG parameter 19. Of course, RBBS-PC allows the
SysOp to determine if callers are reminded of the mail they have left.
In a file specified in CONFIG parameter 93 (the default is CONFMAIL.DEF),
the SysOp can list the message/user file combinations to check for mail
waiting in the format
<user file>,<message file>
where these are related conference file names. If it is assumed that RBBS-
PC is running in a DOS subdirectory off of the main root directory of the
"C:" drive and that there are two conferences, RBBS-PC and BETA, then an
example of the contents of the CONFMAIL.DEF file is:
C:\RBBS\BETAU.DEF,C:\RBBS\BETAM.DEF
C:\RBBS\RBBS-PCU.DEF,C:\RBBS\RBBS-PCM.DEF
The names are processed exactly as typed, so inclusion of the drive/path is
necessary. The SysOp controls what conferences get checked for mail by
listing these file pairs. Conferences not listed will not be checked.
Callers will get a report only for conferences that they are a member of.
Two items of information are reported:
number of new messages since last in the conference, and
whether any new messages are address to the caller.
The name used in RBBS-PC for the main message base is taken from the file
name for the message base. As with conferences - if the prefix of the user
file ends with "M", the name will be the composed of all but the last
character. If the name is "MESSAGES", it will be called "MAIN". Otherwise
the main message base will be called the full prefix.
The main message base and users file can be included in the list to scan.
You may want to coordinate the USERS and MESSAGES file names in the same
fashion that conference user files and message file names are coordinated.
If the main message base is to be known as TOP then call it TOPM.DEF and
call the users TOPU.DEF. RBBS-PC will just as well with the default names
USERS and MESSAGES and call the main message base MAIN.
There are 3 philosophies that can be implemented on message reporting using
the CONFIG parameter 19:
1) Report everything.
2) Make a fast minimal report.
3) Make an optimum intermediate report.
Reporting everything means reminding callers of messages they left, and
give the messages numbers of old and new mail. To do this it is necessary
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 18-2
to set configuration parameters to remind callers of old mail and to report
ALL messages to caller. Also place "sub-boards" and private conferences in
the mail scan list of CONFMAIL.DEF.
Making a fast minimal report means that callers will not be reminded of old
messages, specific message numbers will not be list, only the number of new
messages and whether any are personal will be reported. This option is for
when you want people to get the caller to the command level as fast as
possible. For example, the main message base is not even used. To do this
set configuration parameters to NOT remind callers of old mail and to
report NO messages to caller. Put the main message base as well as "sub-
boards" and private conferences in the mail scan list of CONFMAIL.DEF.
Providing an optimum intermediate report means reporting individual message
numbers only for the new mail as well as # of new messages (and whether any
personal). The best way to implement this is to set the level of reporting
messages to the caller to New Only and to put all "sub-boards" and private
conferences in the mail scan list of CONFMAIL.DEF. Set CONFIG parameter 21
to NOT remind callers of old mail.
RBBS-PC QUESTIONNAIRE FACILITIES 19-1
19. RBBS-PC QUESTIONNAIRE FACILITIES
------------------------------------
RBBS-PC provides a script-driven questionnaire facility. RBBS-PC will
process a questionnaire when a NEW caller logs in, before any caller logs
off, or the user can select a questionnaire from a menu. To ask new users
questions the file named in CONFIG parameter 84 must exist. To ask
questions of users when they say G>oodbye the file named in CONFIG
parameter 85 must exist. Questionnaires can also raise or lower the user's
security level based on his/her responses. Answers to the questionnaire
are appended to a file specified in each questionnaire script.
RBBS-PC will only activate the corresponding script files if they exist,
otherwise the functions are bypassed.
The questionnaire script processor supports:
- Branch to labels (forward and back branching)
- Display lines
- Display line and get response
- Response validation (Multiple choice)
- Numeric validation
- Raising and lowering user security level
- Aborting the questionnaire
- Chaining to another questionnaire
- Invoke a macro from within a questionnaire
- "Turbo" key can be turned on from within a questionnaire
The first line in every script file must contain the file name where the
responses to the script will be appended, and the maximum security level a
user can be raised to. The rest of each script file contains script
commands. Script commands are 1 character in length and must be in column
1 of each script line.
Following is a list and description of valid script commands:
: A colon indicates a label command
* An asterisk indicates a display data command
? A question mark indicates a display and wait for response command
= An equal sign indicates a multiple choice branch command
> A greater than symbol indicates a goto command
+ A plus sign indicates a raise security level command
- A minus sign indicates a lower security level command
@ An "at" sign means to abort questionnaire and do not write results
& An ampersand means to establish a questionnaire chain
T The letter "T" turns on the "turbo" key mode
M The letter "M" executes a "macro"
> Assigns a value to a work variable
CONFIG parameter 94 controls the maximum number of work variables that can
be handled by questionnaires.
RBBS-PC questionnaires even support "graphics" versions of the
questionnaires. Graphics versions use the standard convention of ending
the filename with "C" for color graphics and "G" for ansi graphics. E.g.
HLPRBBSC.DEF and HLPRBBSG.DEF are graphics versions of HLPRBBS.DEF.
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 19-2
19.1 Branching to Labels
------------------------
: Colon (Label command)
This command is used to provide labels that can be branched to from =
and > commands.
:QUESTION1
Numeric labels are not recommended because they are easy to confuse with
work variables. SmartText variables will be interpreted as such, eg.
":-{FN" will substitute the user's first name. SmartText and Work
Variables are dynamically substituted into all questionnaire lines. For
example,
>-.[8].-
will substitute the value of work variable 8 for "[8]", so that if 8 has
"edit" as its value, it will go to the label "-.edit.-".
The ability to get and substitute values, and to have graphics versions,
means that questionnaires can support many of the features of full screen
editing, including transmitting a template, then overlaying values into the
template. An example that shows the power of questionnaires is
?29Change what field (1,2,...20)
?[29]Change field [29]. from [[29]] to
This asks which field to change and stores answer in work variable 29 (i.e.
value of work variable 29 is "7"). The second question then stores the
answer in the value of work variable 29, displays the name of the work
field being changed, and then displays the old value of the work variable.
Suppose that the value of work variable 7 is "Yes". Then the series of
substitutions RBBS-PC makes into the second line before executing it are:
?7Change field [29]. from [[29]] to
?7Change field 7. from [[29]] to
?7Change field 7. from [7] to
?7Change field 7. from Yes to
19.2 Display Data Command
-------------------------
* Asterisk (Display data command)
This command is used to send data to the user. SmartText and Macro
commands are interpreted before display (see section 7.8). "*/FL" will not
display the "/FL" because it is interpreted as a macro command. If you
want to work variables to overlay a display template, keeping it's length
(e.g. for columnar display), put "/FL" after the "*". E.g. if variable 1
has value "12345" and 2 has "abcdef", then
*/FL.[1]....[2]......
will display ".12345..abcdef...", whereas
*.[1]....[2]......
will display ".12345....abcdef......".
One of the more useful capabilities of macros that questionnaires can make
use of is the ability to append data to any work file, where work variables
RBBS-PC QUESTIONNAIRE FACILITIES 19-3
are merged into a form. This allows the questionnaire data to be saved in
virtually any format desired.
The other extremely useful macro capability that questionnaires can utilize
is the ability to retrieve data from a file into a form, in effect adding a
data based file retrieval capability.
19.3 Display Data And Get Response
----------------------------------
? Question mark (Display data and get response)
This command is used to send data to the user and wait for a response.
The user will be required to input a response. The ENTER key alone is an
invalid response. No other checks are made.
?DO YOU OWN YOUR OWN PC? (Y/N)
The prompt command accepts an optional number which is interpreted as the
number of the Work Variable to store the answer in. For example, "
?8Enter Dept
will store the answer not only in the regular way for a questionnaire but
also in work variable 8.
19.4 Multiple Choice Response
-----------------------------
= Equal sign (Response validation - Multiple choice)
This command is used in conjunction with the ? command and must
immediately follow the ? command for which it applies. This command allows
for checking/editing of single character responses to the preceding ?
command and allows branch logic to be exercised based on the response
given. Multiple = commands must be coded on the same line. The format
follows:
=AXXXXXXXXX=BYYYYYYYYY= ZZZZZZZZZZ
= Indicates that a single character comparison value follows
A Is the comparison value
X Is the label to branch to if the response is "A"
= Indicates that a single character comparison value follows
B Is the comparison value
Y Is the label to branch to if the response is "B"
= Indicates that a single character comparison value follows (SPACE)
This is a special comparison value that is always used as the last
comparison value and means "INVALID" response given
Z Is the label to branch to if an invalid response is given
Maximum line length is 255 characters and the last = on the line "MUST"
have a comparison value of " " (SPACE).
:QUESTION1
?Do you run a BBS system. (Y/N)
=YQUESTION2=NQUESTION2= QUESTION1E
:QUESTION1E
*Please respond Y or N
>QUESTION1
:QUESTION2
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 19-4
There is an additional format for the = command, where the comparison
value of # (Pound sign) is used. This is used as a numeric check and
encompasses 0-9, (), - and space. This format requires two entries.
The first is to test for numerics and the second is the invalid response
branch label (e.g. "=#QUESTION3= QUESTION2E").
19.5 Forward And Backward Branching
-----------------------------------
> Greater than sign (Forward and backward branching)
This command is used to branch to specific labels within the script
file.
>QUESTION4
19.6 Raise/Lower User's Security Level
--------------------------------
+ Plus sign (Raise user security level)
This command will add the value in columns 2-6 to the default security
level given new users or the current security level of old users.
+5
- Minus sign (Lower user security level)
This command will subtract the value in columns 2-6 to the default
security given new users or the current security level of old users.
-1
19.7 Abort Questionnaire
------------------------
@ At sign (Abort questionnaire)
This command will terminate the questionnaire and NOT write the response
to the output file as in the following example.
:QUESTION1
?Have you answered the questionnaire before. (Y/N)
=YQUESTION2=NQUESTION3= QUESTION1E
:QUESTION1E
*Please respond Y or N
>QUESTION1
:QUESTION2
@
:QUESTION3
19.8 Chain Questionnaire
------------------------
& Ampersand (Chain questionnaire)
This command will establish the next questionnaire in the chain. The file
named in columns 2-80 will be used as a continuation to the current
questionnaire when the current questionnaire reaches its last line.
i.e. &L:\RBBS\QUESCONT.DEF
19.9 Turbo Keys
---------------
T Turbo Key
RBBS-PC QUESTIONNAIRE FACILITIES 19-5
This is used to turn on Turbo Key for a prompt where a single keystroke is
expected. TurboKey causes the next keystroke to be taken as the answer
immediately without having to press Enter, if the caller has TurboKey on.
19.10 Macro Execute
-------------------
M Macro Execute
This command is used to execute a specified macro named after the command,
e.g. "M C:\RBBS\FIZ.IMC". Control returns to the questionnaire after a
macro is executed. One of the most important capabilities macros add to
questionnaires is the ability to append data to any file in any format
desired. Hence the data in questionnaires can be saved where ever desired
in whatever format desired. If a macro saves the data and you do not want
the normal output on completion of the questionnaire, just abort the
questionnaire at the end. Macros also have the ability to retrieve data
from files and then display on the screen.
19.11 Assign Value
------------------
< Macro Assign
This command assigns a value to a work variable. For example, "<2 XT"
assigns value "XT" to work variable 2.
RBBS-PC's STANDARD INTERFACE FOR PROTOCOL DRIVERS 20-1
20. RBBS-PC's STANDARD INTERFACE FOR PROTOCOL DRIVERS
-----------------------------------------------------
RBBS-PC includes a flexible interface for implementing file-transfer
protocols. A "protocol" for the exchange of files is just a set of
cooperative conventions that allow two different computer's software to
transfer files between themselves. RBBS-PC supports four "protocols"
within its own BASIC source code -- ASCII, Xmodem (checksum), Xmodem (CRC),
and 1K-Xmodem. These are totally configurable by the SysOp when setting up
RBBS-PC.
In addition to these four "protocols" and in order to provide advocates of
specific protocols a means of adding their particular flavor of
communications protocol to RBBS-PC, a standard interface has been created
so that "external" protocols can be installed in RBBS-PC. "External"
protocols are simply defined as programs outside of RBBS-PC which perform
the file transfer.
Before calling "external" protocol drivers, RBBS-PC will do the following:
1) verify that the file exists if the file is to be downloaded.
2) for uploads, verify that the file name requested is valid.
3) pass control of the communications port to the external protocol.
RBBS-PC will call the external protocol drivers either via the SHELL
command in BASIC or via a .BAT file.
20.1 Parameters passed to a protocol driver
-------------------------------------------
RBBS-PC detects the installation of external file transfer protocols via an
optional RBBS-PC system file whose default name is PROTO.DEF. If no such
file exists, only internal protocols will be available -- Ascii, Xmodem,
XmodemCRC, 1K-Xmodem. This file may be used to rename or delete some or
all of RBBS-PC's internal protocols. If a PROTO.DEF file exists, all of
RBBS-PC's internal protocols must be specified in it as well. Internal
protocols are NOT automatically included when a PROTO.DEF file exists!
The protocol definition file has thirteen (13) parameters passed for each
external protocol defined for RBBS-PC. Each parameter can be on a separate
line of its own or all parameters can be on a single line (separated by
commas). The parameters passed for each protocol specified are:
Parameter Description
1 Protocol Name
2 Security Level required to use protocol
3 Method to invoke protocol
4 Whether 8 bit connection required
5 Whether "reliable" connection required
6 Whether "batch" mode supported
7 Number of bytes in a block transferred
8 Indicate transfer always successful
9 Factor to estimate file transfer time
10 RBBS-PC "macro" to invoke before protocol
11 Method for checking transfer's success
12 Template to use for downloading
13 Template to use for uploading
Protocol Name -- The FIRST CHARACTER is the letter by which a caller
selects the protocol. The prompt for the selection of protocol includes
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 20-2
the protocol name. It is recommended that the second character be ")" to
resemble the rest of the prompts in RBBS-PC, e.g. "Z)modem". RBBS-PC will
normally put each protocol on the same line, separated by a comma, until
the line gets too long. The SysOp can control the placement of the line by
putting a carriage return line feed at the end of the protocol name. If
this is done, the entire protocol name must be in parentheses. For
example, instead of the prompt
A)scii,X)modem,C)rcXmodem,Y)modem,N)one
a SysOp may want the prompt to be
A)scii (text files only)
X)modem checksum
C)rc Xmodem
Y)modem (1K Xmodem)
N - None (cancel)
Then the protocol definition file , PROTO.DEF, should be constructed using
quotes (to include the carriage return/line feed in the first parameter) as
follows:
"A)scii (text files only)
",...
"X)modem checksum
",...
"C)rc Xmodem
",...
"Y)modem (1K Xmodem)
",...
"N - None (cancel)
",...
with the remaining 12 parameters put where "..." occurs.
Security Level -- This is the minimum security to be able to use the
protocol being described.
Method to Invoke Protocol -- A protocol can be invoked by one of three
methods:
shell,
door, or
internal (S, D, or I).
If "I" is specified, it must be immediately followed by a letter specifying
what internal protocol to use, where the choices are A, X, C, Y, or N
respectively for Ascii, Xmodem, Xmodem CRC, 1K-X(Y)modem, or None (cancel
transfer). "IC" would mean to use RBBS-PC's internal Xmodem CRC. If no
protocol is specified equivalent to the internal "None", RBBS-PC will add
it. If the letter N is used for a transfer protocol, another protocol must
be specified that is equivalent to "None".
Whether to Require 8 Bit -- By putting "8" in this parameter, the SysOp is
specifying that the protocol requires the caller to be able to send or
receive 8 data bits. If 8 data bits is required and the caller is not at 8
bit, RBBS-PC will prompt the caller to change to 8 bit in order to use the
protocol.
RBBS-PC's STANDARD INTERFACE FOR PROTOCOL DRIVERS 20-3
Whether A Reliable Connection Is Required -- By putting "R" in this
parameter, the SysOp is specifying that the protocol will not be shown or
made available to the caller unless the connections is reliable (i.e. such
as Microcom's MNP protocol that is built into many modems).
Whether Batch is supported -- By putting "B" in this parameter, the SysOp
is indicating that "batch" file transfers are allowed with the protocol.
"Batch" means a multi-file download request will be processed together.
RBBS-PC enters an external protocol only once to do multiple file
downloads. RBBS-PC has been tested with such "batch" protocols as Omen
Technologies' DSZ Zmodem, Megalink, and Sealink.
Blocksize -- This parameter indicates the number of bytes in each block
transferred. This is only used to inform the caller the number of blocks
to expect when downloading. A zero in this parameters will cause RBBS-PC
to report only the number of bytes to expect. For Xmodem or XmodemCRC this
value would be 128. For Ymodem this value would be 1024.
Indicate Transfers Always Successful -- If there is no way for the protocol
to inform RBBS-PC if a transfer was successful, put a "F" in this
parameter, which stands for "Fake" a success report. This means that all
transfers will be regarded as successful.
Zmodem (DSZ) used in a multi-tasking DOS environment (where the DOS
environment variables are shared) and CLINK are examples of protocols that
require this to be set.
Factor to Estimate File Transfer Time -- This is the decimal number used by
RBBS-PC to estimate the elapse time to download a file. The higher the
number, the faster the protocol and the lower the time estimate. Standard
equivalents in RBBS-PC are:
Ascii ......... 0.92
Xmodem ........ 0.78
XmodemCRC ..... 0.78
Kermit ........ 0.78
Ymodem ........ 0.87
Imodem ........ 0.90
YmodemG ....... 0.95
Windowed xmodem 0.78
If no value is specified, a default of 0.87 will be used.
RBBS-PC "Macro" to Invoke Before Protocol -- This is the RBBS-PC "macro"
(i.e. a series of standard RBBS-PC commands) to invoke before invoking the
protocol. It can be used to display special messages, to delay the start
of the protocol, or to prompt for special information passed to the
protocol.
Method for Checking Transfer's Success -- This is required only for
external protocols. This parameter indicates how RBBS-PC is to detect a
file transfer's failure. The format is "x=y=z" where:
x is which parameter tells whether the transfer was successful,
y is the string which indicates failure, and
z is an optional parameter telling RBBS-PC whether to write out
information needed when DOORing to a protocol in advance of the
file exchange.
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 20-4
For QMXFER.EXE from John Friel and the Forbin Project, this would be "4=F"
- meaning the 4th parameter indicates failure if it begins with "F".
For Zmodem as implemented in DSZ from Omen Technologies, the proper choice
depends on whether SHELLing or DOORing is used. For SHELLing, put in
"1=E" to indicate that the first parameter uses "E" to indicate an error
has occurred. For DOORing, put in "4=E=A" to indicate that the fourth
parameter uses "E" when an error has occurred. The "=A" means that RBBS-PC
is to do an advance write of the filename and protocol used. DSZ then
appends its error report to the log file. To the file "XFER-" plus node #
plus ".DEF" RBBS-PC will write out a line containing "<filename>,,<protocol
letter>". Omitting an "=" causes a default to "4=F". The file checked is
"XFER-" plus the node number plus the extension "DEF". On node 1 the file
checked is "XFER-1.DEF".
Template to Use for Downloading -- This is required only for external
protocols. It tells RBBS-PC how to invoke a download. See section 20.2.
Template to Use for Uploading -- This is required only for external
protocols. It tells RBBS-PC how to invoke an upload.
20.2 Calling external protocols using "templates"
-------------------------------------------------
A "template" is used to inform RBBS-PC how to invoke an external protocol.
The first word of the template must be the file name (including file
extension) of the program to invoke. RBBS-PC will check to make sure that
the file exists. If the file does not exist, the protocol will not be made
available to the caller.
RBBS-PC will dynamically substitute values for pre-defined strings inside a
"template". Each supported string is enclosed in square brackets. The
strings supported include:
[n] where n is a positive integer. Substitutes value in a work array
Macros can store the prompted values in specific elements in the
array.
[FILE] Name of the file (FILE.NAME$) to be transferred.
[BAUD] Baud rate. Speed at which the caller dialed RBBS-PC.
[PARITY] Parity used by the caller.
[PORT] DOS device name for the communications port to be used for the
file transfer (COM1,COM2, etc.).
[PORT#] Number of the communications port to be used for the file
transfer (1,2,3, etc.).
[NODE] Number of the RBBS-PC node invoking the file transfer (1,2,3,
etc.).
[PROTO] Letter of the protocol for the file transfer.
Everything else in a template will be passed intact. If the external file
transfer is to be invoked via a SHELL, it is recommended that the external
file transfer program be SHELLed to directly. If the external file
transfer is to be invoked via a DOOR, it can be either
RBBS-PC's STANDARD INTERFACE FOR PROTOCOL DRIVERS 20-5
1) DOORed to directly using the same template as for SHELLing, or
2) DOORed to indirectly via a .BAT file with the command parameters
passed to it by RBBS-PC. For example, a "door" for QMXFER might have
a download template of:
"RBBSQM.BAT [FILE] [PORT] [BAUD] [PROTO]"
and the file RBBSQM.BAT have the following in it:
C:QMXFER.COM -s -f %1 -l %2 -c -b %3 -p %4
DOS substitutes the passed parameters for the variables beginning with the
percent sign. .BAT files are needed if additional programs to run before
or after the actual file transfer.
The following examples should provide some help in understanding how to
invoke external protocols:
Example #1:
Z)ippy,5,S,8,,,,,0.98,,,"c:\utl\zippy -s [FILE]","c:\utl\zippy -r [FILE]"
Can be interpreted to be:
used "Z" as invoking letter,
put "Z)ippy" in the prompt,
the minimum security to use this protocol is 5,
the protocol will be invoked via a SHELL command,
an 8-bit connection is required,
estimate the download time as 0.98 times as fast as normal,
use normal RBBS-PC type of report to check for a successful transfer,
invoke the protocol for downloads using the following string:
"c:\utl\zippy -s [FILE]"
and invoke the protocol for uploads using the following string:
"c:\utl\zmodem -r [FILE]"
where the file name is substituted for "[FILE]" in either case.
Example #2:
X)modem,5,IX,8,,,128,,0.8,,,,
Can be interpreted to be:
used "X" as invoking letter,
put "X)modem" in the prompt,
the minimum security to use this protocol is 5,
the protocol is an internal RBBS-PC protocol,
an 8-bit connection is required, and
estimate the download time as 0.8 times as fast as normal.
20.3 Parameters Returned by a Protocol Driver
---------------------------------------------
All protocol drivers are expected to return information about the file
transfer in a file named XFER-xx.DEF where the value for xx is the node ID
(1 to 36). If the protocol cannot accommodate this minimal requirement, it
can still be used by telling RBBS-PC to indicate file transfers are always
successful -- section 20.1, parameter 8.
The one item of information RBBS-PC requires to be returned from an
external protocol drive is whether or not the file transfer was successful.
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 20-6
The failure indicator MUST BE the first character of any specified
parameter in the file XFER-xx.DEF. To show that file transfer failures are
indicated by the first parameter and the letter "E" in the file
XFER-xx.DEF, parameter 11 (as described in section 20.1) would be written
as "1=E". To show that file transfer failures are indicated by the fourth
parameter and the letter "F", parameter 11 (as described in section 20.1)
would be written as "4=F".
No other information is required when SHELLing to external file transfer
protocols. However, when DOORing to external file transfer protocols the
log file for the transfer MUST HAVE the file name as the first parameter.
Protocol drivers that do not have the file name as the first parameter can
still be used by telling RBBS-PC to write out three parameters (file name,
an empty parameter, and the letter of the file transfer protocol) before
invoking the external file protocol. This is done by using parameter 11
(as described in section 20.1). As an example, to DOOR to an external file
transfer protocol that indicates a file transfer failure by using the
letter "F" in the fourth parameter, but which does not return the file name
used, parameter 11 (as described in section 20.1) would be written as
"4=F=A". The external protocol would then append its own information to
the log file.
20.4 The Protocol Drivers Tested With RBBS-PC
---------------------------------------------
RBBS-PC has been tested with the following protocol drivers:
CLINK From System Enhancement Associates. Supports batch file
transfers, but requires that transfers always be assumed
successful.
DSZ From Omen Technologies. Supports Ymodem, Ymodem Batch, YmodemG,
and Zmodem. YmodemG requires a "reliable" connection. DSZ logs
the results of the file transfers to a file specified in the
environment variable DSZLOG. Therefore, the AUTOEXEC.BAT file
for an RBBS-PC that uses DSZ should specify
"SET DSZLOG=XFER-x.DEF"
where x is the node number. DSZ seems unable to create a log
file whenever a drive or path is specified. If invoking ZMODEM
via the DOOR mechanism, use the "=A" option at the end of the
success method check so that RBBS-PC will append the information
to the DSZ log it needs and DSZ will then append the success
report. In a multi-user environment where a different
environment variable for each node can not be specified (i.e. all
nodes must share the same DSZ log file), specify that all
transfers are always successful for protocols handled via DSZ.
MLINK MEGALINK protocol supports batch file transfers but requires that
transfers always be assumed successful.
PC-KERMIT from Columbia University. PCKERMIT.EXE is supplied by The Source
as a public service and consists of sliding window KERMIT
protocol. The development of "windowing" within the KERMIT
architecture (i.e. Super KERMIT) was funded by The Source and
implemented by Larry Jordan and Jan van der Eijk.
RBBS-PC's STANDARD INTERFACE FOR PROTOCOL DRIVERS 20-7
Columbia University holds the copyright and maintains the Kermit
protocol. Like RBBS-PC, Columbia University allows KERMIT to be
passed along to others and "ask only that profit not be your
goal, credit be given where it is due, and that new material be
sent back to us so that we can maintain a definitive and
comprehensive set of KERMIT implementations".
PCKERMIT.EXE is not a terminal program. It simply implements the
Kermit protocol, including the sliding window extension. It will
work with older "Kermit Classic" implementations as well, via
automatic negotiation between the two Kermit programs.
PCKERMIT.EXE runs as a "one-shot" execution then returns to
RBBS-PC. PCKERMIT does not establish a carrier with a remote
system. The connection is established by RBBS-PC. File
transfers must always be assumed successful.
QMXFER is supplied by The Forbin Project. It supports XMODEM
(checksum), XMODEM (CRC), YMODEM, YMODEMG, and IMODEM. YMODEMG
and IMODEM are designed to work when the link between the two
modems is "error free" (i.e. both modems have the MNP protocol
built in). QMXFER.COM runs as a "one-shot" execution, then
returns to RBBS-PC. QMXFER does not establish a carrier with a
remote system. The connection is established by RBBS-PC. File
transfer failures are indicated by an "F" in the fourth parameter
of the log file returned to RBBS-PC.
WXMODEM is supplied by The Forbin Project, and supports the window XMODEM
protocol designed by Pete Boswell. Like all of RBBS-PC's
protocol drivers, WXMODEM.COM runs as a "one-shot" execution then
returns to RBBS-PC. WXMODEM does not establish a carrier with a
remote system. The connection is established by RBBS-PC. File
transfer failures are indicated by an "F" in the fourth parameter
of the log file returned to RBBS-PC.
Other protocols tested with RBBS-PC include SuperK, Jmodem and Puma.
UPLOADED FILE TIPS 21-1
21. UPLOADED FILE TIPS
----------------------
Every SysOp should assume that any file uploaded to him that can be
executed (i.e. .BAS, .COM, .EXE) has the capability of destroying all the
files available to the PC it is executed on. This may be because the
documentation is in error, the program was executed incorrectly, or the
program was designed to be malicious. It behooves every SysOp to know what
every uploaded file does in order to protect not only the RBBS-PC system,
but its users.
DUE WARNING AND SYSOP'S LEGAL LIABILITY 22-1
22. DUE WARNING AND SYSOP'S LEGAL LIABILITY
-------------------------------------------
While no definitive case-law or legislation exists defining the liabilities
of System Operators, every SysOp should assume that they are as responsible
for their own actions when running an electronic bulletin board system as
they would be for any other action as a citizen of the United States who
chooses to exercise their right to freedom of speech. One of the unique
features of RBBS-PC is that users have to OVERTLY register themselves --
even when the RBBS-PC is "open" to the general public. This gives each
SysOp the opportunity to give every user "due notice" and require each user
to actively acknowledge such notice. Every SysOp should consider the legal
issues, and provide proper notice to all callers.
COMPILING AND LINKING RBBS-PC 23-1
23. COMPILING AND LINKING RBBS-PC
---------------------------------
RBBS-PC source code is distributed along with the executable program RBBS-
PC.EXE. It is NOT necessary to recompile or re-link RBBS-PC in order to
utilize RBBS-PC. This section is intended for those hardy few who choose
to modify the source and recompile it. Remember only what is distributed
is supported -- anything else is strictly yours to debug!
RBBS-PC's source code is compilable by the Microsoft QuickBASIC Compiler,
version 2.01 and higher. However Microsoft's QuickBASIC Compiler version
3.0 is the compiler used to generate the .EXE files distributed with
RBBS-PC because it appears to be the most reliable. Versions too buggy to
use at all include 1.0, 2.0, and 4.0.
The batch files MAKERBBS.BAT and MAKECNFG.BAT are included with the source
to recompile RBBS-PC and CONFIG respectively. They are designed for use
with QuickBasic 3.0 but instructions for other versions of the compiler are
in them. The DTR patch described in Appendix G should be applied before
you compile RBBS-PC.
LIMITED LICENSE 24-1
24. LIMITED LICENSE
-------------------
The RBBS-PC software is copyrighted but A LIMITED LICENSE IS GRANTED and
each user is free to use and share it under the following conditions:
1. You may NOT distribute RBBS-PC in modified form.
2. You may NOT charge a fee for RBBS-PC itself, and
3. You MUST retain all references to the copyright and authors.
Please distribute the original version (or update thereof) of the program.
If you have changes please distribute them using the conventions described
in section 1.4. This is necessary so that future revisions can be easily
added to the system without requiring the entire program.
Please do NOT resequence the program. All revisions will be as files that
replace the base program or update thereof and the existing line numbers
will be referenced when describing new fixes and enhancements.
LIMITED WARRANTY 25-1
25. LIMITED WARRANTY
--------------------
The RBBS-PC program is provided "as is" without warranty of any kind,
either expressed or implied, including but not limited to the implied
warranties of merchantability and fitness for a particular purpose. The
entire risk as to the quality and performance of the program is with the
user, and should the program prove defective, the user and not the authors
will assume the entire cost of all necessary remedies. None of the authors
warrant that the functions contained in the program will meet any users'
requirements or that the operation of the program will be uninterrupted or
error-free. In any case, each author's entire liability will be limited to
the total amount of money the individual user paid directly and explicitly
to each author for the use of RBBS-PC.
THE HISTORY BEHIND RBBS-PC 26-1
26. THE HISTORY BEHIND RBBS-PC
------------------------------
Electronic bulletin board systems have been around ever since personal
computers existed. The first ones were very primitive and usually
consisted of some posted notices and maybe allowed for on-line messages.
It must be remembered that the IBM PC was only announced in August of 1981
and first became available in October of 1981. Therefore it is not
surprising that the early history of BBS' is associated with non-IBM
personal computers.
The "early history" of bulletin board systems began around 1978 in Chicago
with the CBBS/Chicago (Computerized Bulletin Board System/Chicago). It was
created by Ward Christensen and Randy Suess -- members of the Chicago Area
Computer Hobbyist Exchange (CACHE). CBBS for the CP/M is written in 8080
Assembler language (11,000 lines of it) and, like the early versions of
RBBS-PC (i.e. prior to 12.5A), detects the baud rate and the parity of the
user when he first signs on from the three carriage returns that the user
must enter.
About the same time, Bill Abney wrote a BBS for the Radio Shack TRS-80
Models I and II called Forum-80.
The earliest BBS was written for the Apple (who else had personal computers
in those days?) called the "Apple Bulletin Board System" (ABBS). It was
written by Craig Vaughn and Bill Blue. They later created another bulletin
board system for the Apple II called the People's Message System (PMS).
Another Apple bulletin board system that came into being was for the Apple
II, II+, and IIE as well as the Franklin Ace and it was called the
CommuniTree. It was written in the FORTH language by Dean Gengle and
several others.
When IBM announced its first personal computer, the IBM PC, in August of
1981, there was no BBS for it. In the summer of 1982, Brad Hanson found a
prototype version written by Russ Lane in IBM's BASIC on David Crane's
Dallas RCP/M\CBBS system. Brad added many fixes and modifications. In the
first half of 1983, many members of the Capital PC Users Group's
Communication Special Interest Group (SIG) such as Larry Jordan, Rich
Schinnell, Gary Horwith, Jim Fry, Scot Loftesness, and Dorn Stickle further
enhanced it and added XMODEM file transfer capability until it became known
as RBBS-PC CPC09 in May of 1983. At that time each feature or modification
was identified by a new version number; it still ran only under the BASIC
interpreter; and was both relatively slow (because of the interpreter) and
somewhat unstable (it would normally "crash" at least once each day).
In June of 1983, Tom Mack received a copy of RBBS-PC CPC09 from Rich
Schinnell. Tom's efforts were instrumental in making RBBS-PC what it is
today - the industry-standard PC-based BBS software. Other contributors
have come and gone, but Tom's contribution to RBBS-PC can never be matched.
RBBS-PC's impact has been to open an entirely new medium of communications
between people. Rather than as an end in and of itself, RBBS-PC has come
to serve as a means to an end -- the free exchange of ideas. On a
technical level it is certainly an example that shows "real programmers
can/do program in BASIC." We would like to think that RBBS-PC had
something to do with IBM and Microsoft coming out with new versions of the
BASIC compiler that support communications, sub-routines, local and global
variables, file-locking in a networking environment, etc.
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 26-2
RBBS-PC represents a fundamental cornerstone, not just a phase, in what can
be viewed as a "social renaissance." RBBS-PC eliminates those barriers
that had previously inhibited the "exchange" of information within our
society. RBBS-PC provides every personal computer owner with his own
"soap-box" in a national Hyde Park. Previously the channels of
communication had built-in barriers to "exchange"; with RBBS-PC those
barriers begin to cease to exist.
While only the most fanatical RBBS-PC trivia experts may be interested,
here is the chronology:
RBBS-PC Initial Major Enhancements
Version Release
Number Date
10.0 07/04/83 RBBS-PC first written to be compilable by IBM's BASIC
compiler, version 1.0
11.0 08/10/83 RBBS-PC restructured so that all parameters were
external (i.e. in the RBBS-PC.DEF) allowing SysOps who
didn't want to spend the $300 for the BASIC compiler to
tailor RBBS-PC to their taste. CONFIG.BAS was first
written to generate RBBS-PC.DEF.
11.1 09/15/83 Jon Martin contributed UTSPACE.OBJ, a sub-routine that
allowed the compiled version of RBBS-PC to determine
the amount of free space available for uploading.
11.2 10/01/83 The error trapping within RBBS-PC was completely re-
written to be more comprehensive.
12.0 10/28/83 Tree-structured file directories and the ability to
detect that RBBS-PC was in a "MultiLink" environment
were incorporated. "MultiLink" is a product of the
Software Link, Inc. which allows DOS 1.1, 2.0, 2.1, 3.0
and 3.1 to be "multi-tasking."
12.1 12/18/83 The ability for a SysOp who signed on remotely to drop
(Versions into DOS was added. Also the "New" command
was added "A" to "F")that allowed users to determine
what new files had been made available since the last
time they were on.
12.2 04/08/84 The security system designed by Ken Goosens was
incorporated.
12.3 11/11/84 Up to nine RBBS-PCs can share the same files in either
a multi-tasking DOS environment (i.e. MultiLink from
the Software Link, Inc.) or in a local area network
environment (i.e. Corvus or Orchid).
12.4 03/10/85 (Version A, A1, B) RBBS-PC's stature in the industry
became recognized when, RBBS-PC was granted a license
by Microcom to incorporate their proprietary MNP
protocol. "RBBS-PC compatibility" became a minimum
criteria for the introduction of products by many
companies. RBBS-PC introduces 300/1200/2400 BAUD
support in 12.4A before most such modems were generally
available.
THE HISTORY BEHIND RBBS-PC 26-3
12.5 07/14/85 (Versions A and B). 36 copies of RBBS-PC could share
the same files in a network environment. RBBS-PC
automatically answers the phone and no longer requires
each caller to enter up to 3 carriage returns in order
for RBBS-PC to detect the users baud rate and parity.
Logon to RBBS-PC has been made much more efficient with
the USERS file no longer being searched sequentially
and the MESSAGES file no longer being read three times.
Version 12.5B, released August 25, 1985, WAS THE LAST
VERSION COMPILABLE BY VERSION 1.0 OF THE IBM BASIC
COMPILER!
13.1 12/01/85 IBM BASIC compiler and Microsoft's QuickBASIC Version
1.0 supported. XMODEM with CRC was added as a
file-transfer protocol as well as the ability to
display on the color monitor of the PC running RBBS-PC
the color/graphics that the remote user sees exactly as
he sees them.
14.1 03/16/86 (Versions A, B, C, and D) RBBS-PC's internal structure
was split into two parts - RBBS-BAS for the main-line
source code and logic, and a RBBS-SUB.BAS for commonly
called subroutines. Support for on-line
questionnaires, auto-downloading, and the KERMIT
protocol were also included as well as the option to
utilize assembly language subroutines to increase for
better performance over their BASIC counterparts.
15.1 03/15/87 File Management System for directories added. User
subscription management added. The ability to run as a
local application on a network, configurable command
letters, the ability to use any field or to define a
new field to identify callers, the ability to
individuate callers having the same ID, multiple
uploads on a single command line, new A)nswer and
V)erbose ARC list commands, context sensitive help,
and a new subsystem for software "libraries".
16.1 03/27/88 (Version A) Major enhancements included the addition of
"sub-boards" (i.e. conferences with their own
bulletins, file areas, menus etc.), a programmable user
interface, the capability to have SysOp-written
"sub-menus" for any command, the ability to hang off of
a public data network such as Compuserve's as a "node",
the incorporation of "personal downloads" (i.e. files
only specific individuals could list/download), the
ability to vary the amount of time a user has on the
system by the time of day the user logs on, the
capability of preventing any message (public or
private) from being read until the SysOp has reviewed
it, an enhanced CONFIG utility with many more options,
XMODEM/1K protocol built-in to RBBS-PC's main-line
source code, the ability to automatically add users to
conferences, and support for The Software Link's
MultiLink Version 4.0. Despite all these enhancements,
the BASIC RBBS-PC code was significantly enhanced such
that it only requires 268K to run -- allowing two
copies to run in multi-tasking DOS environments that
have 640K available.
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 26-4
17.1 10/02/88 (Versions A, B, C, and D). Major enhancements were made
in the System Support area, and the support for up to
eight communications ports; built-in interfaces to
external communications drivers such as a FOSSIL
driver; automatic notification of the SysOp when
specific users log on; improved automatic invocation of
other applications based on time of day; and
SysOp-selectable time delays that users must wait
before being able to download or exit to a door.
RBBS-PC's unique programmable user interface (PUI) was
enhanced to support "macros" (i.e. use a single command
to invoke any number of RBBS-PC commands);
SysOp-selectable colors for all prompts and messages
(i.e. "colorization"); caller-selectable "colorization"
for text (i.e. color, bold or normal, highlighting of
text, etc.); and personalized text files (i.e. text
files that can dynamically adapt to include information
unique to each caller). The messaging within RBBS-PC
was enhanced to notify each caller that logs on of the
number of new messages and how many are addressed to
the caller for the conferences to which the caller
belongs. The text editor function for messages was
enhanced to allow any character to be edited. RBBS-
PC's standard "threaded" message search now also scans
the text of the messages for matches. The RBBS-PC file
subsystem was also significantly enhanced to include an
unlimited number of installable protocols; batch
downloading for such protocols that support this (i.e.
Zmodem, Megalink, and Sealink); and control of callers
ability to download based on either the number of
characters or the ratio of the callers downloads to
uploads.
17.2 05/28/89 (Versions A-B). Major enhancements consisted of
increased flexibility in invoking external applications
(i.e. "DOORS"), on-line questionnaires, RBBS-PC command
"macros", the integration (using the enhanced
questionnaires and "macros") of on-line data base
facilities into RBBS-PC, as well as extended support in
RBBS-PC's file system to support ANY file compaction
technique (i.e. .ARC, .ZOO, .ZIP, etc.) -- including
allowing on-line users to list text files that have
been included within a compacted file. RBBS-PC's
"NETMAIL" interface to store and forward messaging
systems (i.e. FIDO MAIL, etc.) was enhanced. Within
the messaging subsystem numerous enhancements were
added including the ability to quote all or part of a
message that the caller was replying to. RBBS- PC's
file subsystem was improved to allow the system to be
configured such that all uploads were automatically
checked/verified (by whatever utility the SysOp wanted
to use). RBBS-PC commitment to the concept of "users
helping users" was demonstrated once again with the
incorporation of support for the Computalker and
HEARSAY 1000 speech boards so that seeing-impaired
SysOps could hear (in a meaningful way) the activity
occurring on their RBBS-PC bulletin boards.
THE HISTORY BEHIND RBBS-PC 26-5
17.3 02/11/90 (versions 17.3 & 17.3A) Fast File Search: sub-second
file name looks for over 32,000 downloadable files; up
to 10,098 downloadable areas. Variable names were
changed to MicroSoft standard format using upper and
lower case letters only, and no internal dots. Some 50
bugs were fixed. News facility added. Universal
command stacking. Default extension on file requests.
Enhanced macros and SmartText. Defaults added for
multiple modems. Support for 38,400 baud through
Fossil driver.
PROPOSED RBBS-PC SYSOP CONFERENCE 27-1
27. PROPOSED RBBS-PC SYSOP CONFERENCE
-------------------------------------
As the modem community continues to evolve, RBBS-PC must change to meet the
needs of all users. For years, RBBS-PC has survived with file structures
that are "adequate." However, each passing year brings new uses for
RBBS-PC that place demands on the internal structure of the system.
It is time to discuss the future of RBBS-PC. We would like to see
RBBS-PC's future written in the same spirit that RBBS-PC is developed, by
involving the users. If possible, a SysOp conference can coincide with the
internal restructuring of RBBS-PC. Topics can be discussed such as
RBBS-PC's support of netmail, enhanced messaging features, and an enhanced
USER record structure. This conference cannot succeed without your
support. The timing, location, and agenda for such a meeting is left up to
the RBBS-PC community, but may we suggest a winter retreat in Florida? Who
wouldn't mind spending a few days in the sun, and discussing the future of
RBBS-PC at the same time?
If you are interested in participating, write me at the following address:
Doug Azzarito
RBBS-PC SysOp Conference
5480 Eagle Lake Drive
Palm Beach Gardens, FL 33418
Or call my BBS: (407) 627-6969 or 627-6862.
I would especially like to hear from anyone with experience in organizing a
conference. If you have gone through the process of booking hotels and
meeting space, or other things I probably won't think of, PLEASE let me
know!
RBBS-PC, THE LARGEST SOFTWARE HOUSE IN THE WORLD 28-1
28. RBBS-PC, THE LARGEST SOFTWARE HOUSE IN THE WORLD
----------------------------------------------------
RBBS-PC'S "Userware" concept is founded on the principle stated in section
1.1 -- "software which is shared becomes better than it was." Relying on
Federal copyright protection, we believe that RBBS-PC's source code can be
distributed without the risk of "loss of ownership" (i.e. it becoming
"public domain"). We believe all software (commercial and non-commercial)
should be distributed as both compiled/executable files and with their
source code. With few exceptions, RBBS-PC's copyrights have never been
violated -- this is due more to the fact that RBBS-PC enthusiasts are
ever-vigilant of RBBS-PC's copyrights rather than due to any lack of
attempts to "sell" RBBS-PC or RBBS-PC look-alikes to the unsuspecting
public.
Incorporating these new features and ideas into each new release of
RBBS-PC, making sure that upward compatibility with earlier version of
RBBS-PC exists, as well as maintaining RBBS-PC's copyright, are all things
that the authors accept the responsibility for. However, it is RBBS-PC's
"support staff" (i.e. all those who enhance RBBS-PC and share such
enhancements) that continues to make RBBS-PC a unique experiment in PC
software.
No one should feel that the possibilities for RBBS-PC have even begun to be
exhausted. In fact, we are absolutely certain that even as this is written
innovative enhancements are being created for RBBS-PC. It is our sincerest
hope that if RBBS-PC continues to succeed within the IBM PC industry in
becoming the "bulletin-board standard," software vendors will begin
examining the reasons for RBBS-PC's success and come to understand that:
- The best form of software support is user support
- The best source for software enhancements are from it's users
- The best software continually adopts itself to users needs
- The best way to minimize software development is to distribute source
code.
Each RBBS-PC system operator has the opportunity to affect what RBBS-PC
becomes in the future. Many already have. RBBS-PC continues to grow and
expand because hundreds (and quite possibly thousands) of SysOps spend the
time and trouble not only to modify RBBS-PC to meet their needs, but also
to share these modifications with others. We do not know of any other
software for the IBM PC that has such a vast number of programmers
supporting it. In section 1.3, we name many such individuals and
acknowledge that there are a lot more! With the structured code that the
new BASIC compilers allow, even more RBBS-PC system operators are invited
to contribute. Take the time! Make the difference!
APPENDIX A -- RBBS-PC Record Formats A-1
APPENDICES
APPENDIX A -- RBBS-PC Record Formats
------------------------------------
This appendix is intended to document the record formats of some of the
more significant records used within RBBS-PC. As such, it is intended more
as a "programmers' guide" for those who wish to write RBBS-PC utilities
rather than as "user documentation." No record format is "sacrosanct" and
any of them may be changed in future releases. However such changes are
not made capriciously and, when they are made, are accompanied by some
utility program that will allow the old files to be reformatted into the
new format.
The MESSAGES file contains the messages that have been left on RBBS-PC. It
is a random access file with 128-byte records. The first record of the
MESSAGES file acts as RBBS-PC's "checkpoint" record. The records
immediately following this first record are the RBBS-PC "node" records.
Each "node" record represents the activity/options associated with a
particular copy of RBBS-PC ("node"). There can be up to thirty-six copies
of RBBS-PC running simultaneously, therefore there can be up to thirty-six
"node" records following the "checkpoint" record.
The MESSAGES file has the following logical format:
+----------------------------------------------+
Record #1 | RBBS-PC "checkpoint" record |
+----------------------------------------------+
Record #2 | RBBS-PC "node" record for node # 1 |
| |
| up to |
| |
| RBBS-PC "node" record for node # 9 |
| RBBS-PC "node" record for node # 0 |
| RBBS-PC "node" record for node "A" |
| |
| up to |
| RBBS-PC "node" record for node "Z" |
| |
+----------------------------------------------+
| First Record in Message portion of file |
+----------------------------------------------+
| |
\ Message records that have been used \
\ \
| |
+----------------------------------------------+
| Record available for next message |
+----------------------------------------------+
| Last record available in MESSAGES file |
+----------------------------------------------+
The FIRST RECORD of the "MESSAGES" file acts as a "checkpoint" record for
all the multiple RBBS-PC's that may be sharing the MESSAGES and USERS
files. It contains information critical to maintaining the integrity of
these two files. The layout of RBBS-PC Message File Record Number 1 is
as follows:
Position Length Description
1 - 8 8 Number assigned to the last message entered
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL A-2
9 - 10 2 Security level required to be auto-added to a conference
11 - 20 10 Current caller number
21 - 56 36 --- RESERVED FOR FUTURE USE ----
57 - 61 5 Count of the number of USER records used
62 - 67 6 --- RESERVED FOR FUTURE USE ----
68 - 74 7 Record Number where "messages" portion of the
MESSAGES file begins
75 - 81 7 Record Number of the next available record in the
MESSAGES file where the next message may be written
82 - 88 7 Record Number of the last record in the MESSAGES file
89 - 95 7 Maximum number of messages allowed in the MESSAGES file
96 -126 31 --- RESERVED FOR FUTURE USE ----
127 -128 2 Maximum number of RBBS-PC's sharing this MESSAGES file
As a programming reference, line numbers 1900 and 23000 of the BASIC source
code for RBBS-PC.BAS contains the code for reading this "checkpoint"
record.
Following the first record of the MESSAGES file are from one to 36 "node"
records. Each "node" record contains information critical to the
running of that copy of RBBS-PC associated with that "node". The layout of
each RBBS-PC "node" record is as follows:
Position Length Description
1 - 31 31 Name of last person on this copy of RBBS-PC
32 - 33 2 SysOp available indicator (true or false)
34 - 35 2 SysOp annoy indicator (true or false)
36 - 37 2 SysOp is to be on next indicator (true or false)
38 - 39 2 Line printer available indicator (true or false)
40 - 41 2 Door's availability indicator (true or false)
42 - 43 2 Eight bit transmission indicator (true or false)
44 - 45 2 Caller's baud rate indicator: -1 = 300 bps
-2 = 450 bps
-3 = 1200 bps
-4 = 2400 bps
-5 = 4800 bps
-6 = 9600 bps
-7 = 19200 bps
-8 = 38400 bps
46 - 47 2 Upper case only indicator (true or false)
48 - 51 4 Number of bytes transferred (from external protocols)
52 1 Batch transfer indicator (not zero = batch)
53 - 54 2 Graphics indicator (0 = text, 1 = full ASCII, 2 = color)
55 - 56 2 SysOp indicator (-1 = SysOp)
57 1 Activity indicator (I=inactive, A=active)
58 - 59 2 SNOOP on indicator (true or false)
60 - 64 5 Baud that RBBS-PC talks to the modem at (single precision)
65 - 67 3 Time user logged onto the system (HH:MM:SS)
68 - 71 4 --- RESERVED FOR FUTURE USE ---
72 - 73 2 Private door indicator (true or false)
74 1 Type of transfer to external program:
0 = none
1 = download a file
2 = upload a file
3 = external registration program
75 1 First letter of file transfer protocol
76 1 --- RESERVED FOR FUTURE USE ----
77 - 78 2 Last date, MM-DD-YY, that RBBS-PC exited to DOS (packed)
APPENDIX A -- RBBS-PC Record Formats A-3
79 - 85 7 --- RESERVED FOR FUTURE USE ----
86 - 90 5 Last time, HH:MM, that RBBS-PC exited to DOS
91 - 92 2 Reliable mode indicator (true or false)
93 - 116 24 Work area that normally contains caller's City and State,
but when temporarily exiting RBBS-PC used as:
Position Length Description
93 -100 8 Programmable user interface file name
101 -102 2 Local user indicator (2 hex 0Ds if local)
103 -104 2 Local user mode (true if using COM0)
105 -112 8 Name of current "conference" or "sub-board"
113 -114 2 Time credits (minutes)
115 -116 2 --- UNUSED ----
117 -118 2 Subsystem index of last subsystem user was in.
119 -124 6 Month, day, and year, MMDDYY, exited to external protocol
125 -128 4 Hour and minute, HHMM, exited to external protocol
As a programming reference and in order to see how these fields are
set/used in the node records, review the following line numbers in RBBS-
PC.BAS -- 150, 200, 400, 420, 842, and 13555. In addition, review the
following subroutines as well:
Source Code Subroutine
RBBSSUB2.BAS ---- WhosOn
RBBSSUB3.BAS ---- FindFKey
SaveProf
ReadProf
RBBSSUB4.BAS ---- TimedOut
A message within the messages file consists of a MESSAGE HEADER followed by
the text of the message. The RBBS-PC Message File "message header" record
layout is as follows:
Position Length Description
1 1 Contains an "*" for read-only messages, blank otherwise
2 - 5 4 Message number of this message
6 - 36 31 The name of the person the message is from
37 - 58 22 The name of the person to whom the message is sent
59 - 66 8 Time of day that the message was sent (HH:MM:SS)
67 - 67 1 ---- RESERVED FOR FUTURE USE ----
68 - 75 8 Date the message was sent (MM-DD-YY)
76 -100 25 Subject of the message
101 -115 15 Password for the message (if any)
116 -116 1 "Active" message indicator = ASCII 225
"Killed" message indicator = ASCII 226
117 -120 4 Number of 128-byte records for this message --
including the "message header" record.
121 -122 2 Minimum security level to read message
123 -125 3 Date (packed) the message was last read (MM/DD/YY)
126 -128 3 Time (packed) the message was last read (HH:MM:SS)
As a programming reference, review lines 3405, 3460, 3530, and 8076 of the
BASIC source code for RBBS-PC.BAS to see how these fields are set. Each
record following the MESSAGE HEADER record is a MESSAGE TEXT record and
consists of 128 characters. Each of these 128-byte message text" records
contains the message text. The end of each line in the message is followed
by an RBBS-PC "end-of-line" indicator which is equal to an ASCII 227. This
allows RBBS-PC to "pack" multiple message lines in a single 128-byte
record.
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL A-4
Information unique to each person who logs on is contained in the USERS
file (a random file of 128-byte records). Each records is as follows:
Position Length Description
1 - 31 31 Users first and last name (separated by a blank).
32 - 46 15 Users password for logon.
47 - 48 2 Users security level (permanent).
49 - 62 14 Users logon options (see detail breakdown below).
63 - 86 24 City and state from which the user is calling.
87 - 89 3 ---- RESERVED FOR FUTURE USE ----
90 - 93 4 Number of files downloaded today
94 - 97 4 Number of bytes downloaded today
98 -101 4 Number of bytes downloaded (ever).
102 -105 4 Number of bytes uploaded (ever).
106 -119 14 Date and time the user was last on (MM-DD-YY HH:MM).
120 -122 3 Date the user last listed a directory.
123 -124 2 Number of files downloaded (ever).
125 -126 2 Number of files uploaded (ever).
127 -128 2 Elapsed time the user was on for day of last access.
Line 9400 of the BASIC source code for RBBS- PC.BAS contains the code for
opening this file. The user's logon options, positions 49 through 62, are
utilized as follows:
Position Length Description
49 - 50 2 Number of times the user has logged on
51 - 52 2 Last message number read by the user
53 1 Protocol Preference (blank if none, otherwise letter)
54 1 Graphics Preference (see meaning below)
55 - 56 2 Margin length for this users messages
57 - 58 2 Bit Flag -- this 16-bit field is denoted by bit 0 being
the least significant (i.e. right-most bit) and bit 15 being the most
significant (i.e. left-most bit). These "bit flags" have the following
meanings (0=off, 1=on):
BIT Definition (what ON means)
0 Bell prompts
1 "Expert" mode
2 Nulls
3 Upper case only
4 Line feeds
5 Skip old bulletins
6 Check new files on logon
7 Use autodownload
8 Required questionnaire answered
9 Mail Waiting
10 Highlighting enabled
11 "TurboKey" enabled
12-15 RESERVED FOR FUTURE USE
59 - 60 2 Date subscription began
61 1 Page length to use for this users terminal
62 1 ------- RESERVED FOR FUTURE USE ---------
---
14
The meaning of the graphics preference byte depends on the numeric value it
has. The caller can specify, for text files, no graphics, ascii graphics,
or ansi color graphics; then the color, and then whether normal or bold.
APPENDIX A -- RBBS-PC Record Formats A-5
For example, if graphics preference for text files is color, and preference
for normal text is light yellow, graphics preference stored is 38. Colors
are Red, Green, Yellow, Blue, Purple, Cyan, and White.
normal bold
graphics\color R G Y B P C W R G Y B P C W
none ...... 30 33 36 39 42 45 48 | 51 54 57 60 63 66 69
ascii ...... 31 34 37 40 43 46 49 | 52 55 58 61 64 67 70
ansi ...... 32 35 38 41 44 47 50 | 53 56 59 62 65 68 71
APPENDIX B -- RBBS-PC Software Registration B-1
APPENDIX B -- RBBS-PC Software Registration
-------------------------------------------
Frequent inquires are made asking how many RBBS-PC systems are in
operation, or about a "master" list of RBBS-PC's. Since RBBS-PC is freely
distributed, attempts to get SysOps to register the product have been in
vain. However, in an attempt to help SysOps (and potential SysOps)
everywhere find configurations that most closely match their own, and to
help users find more RBBS-PC systems, we ask that you register your copy of
RBBS-PC. The information you supply will be used to maintain an "ACCURATE"
listing of all publicly available RBBS-PC systems. The success of this
endeavor depends on you. Please complete the BBS info file LG-9999.DEF
supplied with this release of RBBS-PC and send it to:
RBBS-PC SOFTWARE REGISTRATION
P.O. Box 31024
Palm Beach Gardens, FL 33420-1024 U.S.A.
To make sure your registration is current, please remember to send a copy
of your registration form at least once each year. You can also call The
RBBS-PC technical support BBS and upload a copy of the form. An online
database of all respondents will be available on the technical support BBS:
(407) 627-6969 or 627-6862.
If you need a good reason to complete and return the information, read on!
As RBBS-PC continues to evolve, we must make decisions that will affect
you. If we know who you are, and what your environment is like, we are
less likely to introduce a new version of RBBS-PC that will not run in your
environment!
THE BBS IDENTIFICATION STANDARD
-------------------------------
To help BBS list editors, and other users searching for your BBS, we have
started what we hope will be an industry standard. Please implement it on
your BBS. Here's how:
1) Complete the LG-9999.DEF file and place it with your other LGn.DEF
files.
2) Create a user with first name "BBS", Last name "VERIFY", password
"CALL".
3) Set this user's SECURITY to -9999.
Now, any time a BBS list editor calls for a quick check, he'll use the name
BBS VERIFY and a password of CALL. Your BBS will quickly display the
information he needs, and then hang up. Any user who is curious about your
BBS can do the same. If ALL BBS systems implement this, keeping track of
the fast moving BBS community will be much easier. Please, do what you can
to convince other SysOps to implement this simple procedure.
APPENDIX C -- RBBS-PC Subscription Service C-1
APPENDIX C -- RBBS-PC Subscription Service
------------------------------------------
It seems that many people absolutely must be on the bleeding edge of
RBBS-PC and demand each new version as soon as possible after it is
released. For them you can order in advance the next release of RBBS-PC.
It will be mailed anywhere by air mail - overnight in the United States,
ordinary air mail elsewhere. The charge for this subscription upgrade is
$25.
Hopefully, this service will only be used by a very, VERY few! Most
releases have a few fixes that get published within the first week or two
that they are out. Because of this everyone is advised to check back for
fixes after each release goes out.
To obtain this service for the NEXT release (it does NOT apply to the
current or previous releases) fill out the following form and send it along
with your check or money order in U.S. funds (no purchase orders are
accepted and your canceled check is your only invoice).
+------------------------------------------------------------------+
| To: Capital PC Software Exchange RBBS-PC Subscription Service to|
| P.O. Box 6128 the NEXT release of RBBS-PC (if|
| Silver Spring, Maryland any - and none are implied or |
| 20906 promised by this offer) |
|------------------------------------------------------------------|
|Date Requested: Date Received: |
|------------------------------------------------------------------|
|To (Recipient's Name): |
|------------------------------------------------------------------|
|Recipient's Phone Number (required): ( ) - |
|------------------------------------------------------------------|
|Exact Street Address (no P.O. Box or P.O. Zip Code accepted) |
| |
| |
|------------------------------------------------------------------|
| City | State or Country |
| | |
|------------------------------------------------------------------|
| Signature (required) | ZIP Code for Street Address |
| | |
+------------------------------------------------------------------+
Note: this is not a promise that there will be any new releases.
APPENDIX D -- Modems with RBBS-PC D-1
APPENDIX D -- Modems with RBBS-PC
---------------------------------
Introduction
------------
Modems are often frustrating things to get working properly on a BBS.
Some have hardware switches that must be set. When a SysOp finally gets
his own modem to work with RBBS-PC, he will often share his discoveries.
This appendix is a result of such sharing.
Anchor Signalman Express (MK12)
-------------------------------
The following are the switch and jumper settings for the Modem.
Switch 1 = Off
Switch 2 = Off
Switch 3 = On
Switch 4 = On
Switch 5 = On
Switch 6 = On
Switch 7 = On
Switch 8 = On
Ark-Paradyne
------------
The ARK Modem is somewhat Hayes compatible, therefore some changes must be
made to use this modem. Because of major improvements in RBBS-PC, the
modem can now be used in both of its modes, Normal and Hayes. To use the
HAYES (tm) mode follow this procedure:
A.) Using CONFIG.EXE supplied with RBBS-PC, select and change the following
parameters:
Parameter 224 Number of rings to wait before answering -------- 1
Do you want ringback? (YES/NO) ----------------- NO
Parameter 225 Use the RBBS-PC default Hayes commands?--------- NO
1. Reset the modem ------ : ATZ or ATV0Z
2. Initialize the modem - : ATM0Q0S2=255S10=30E0S0=0
(Note the use of "Q0" to initialize the modem)
3,4,5 Use the defaults supplied
Parameter 227 Issue modem commands between rings ------------ YES
Parameter 228 Baud rate to initially open modem at --------- 2400
Parameter 237 Leave modem at initial baud rate --------------- NO
Parameter 244 Modem flow control uses Clear-to-Send (CTS) ---- NO
Parameter 245 Modem flow control uses XON/XOFF --------------- NO
For the ARK 24K (not 24K PLUS) use the following switch & jumper settings:
Switch 1 UUUDDUUD (where U = Up = On and D = Down = Off)
Switch 2 UDDDDUDD
Switch 3 DUUDUUUU
MODEM DTE/CLOCK FLOW BUSY DTR
JUMPERS E8-E9 E15-E16 E4-E7 E11-E14
For the ARK 24K PLUS use the following:
Switch 1 UUUDDUUD last down = Hayes mode
Switch 2 UDDDDUDD first up = auto answer off
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL D-2
Switch 3 DUUDUDDD last three down = "auto baud"
Modem Jumpers - Use the factory defaults on all
B.) You can also use the ARK NORMAL mode with a fixed terminal rate. The
modem talks to RBBS-PC at 2400 and talks to your user at 300, 1200, 2400.
One problem noted was that upon return from dropping to DOS, the baud rate
reverted back to 2400. If you were remote and using a 1200 baud modem,
things get very messy. It has been noted with some external protocols that
a similar problem exists. I don't recommend this setting unless you are
willing to take some risks. You must also use flow control. Make the
settings as follows:
Parameter 224 Number of rings to wait before answering -------- 1
Parameter 225 Use the RBBS-PC default Hayes commands?--------- NO
1. Reset the modem ------ : ATV0Z
2. Initialize the modem - : ATM0Q0S2=255S10=30E0S0=0
3,4,5 Use the defaults supplied
Parameter 227 Issue commands between rings ------------------ YES
Parameter 228 Baud rate to initially open modem at --------- 2400
Parameter 237 Leave modem at initial baud rate -------------- YES
Parameter 244 Modem flow control uses Clear-to-Send (CTS) --- YES
Parameter 245 Modem flow control uses XON/XOFF -------------- YES
The following is recommended for the ARK 24K Modem:
Switch 1 UUUDDUUU (NOTE 8th position) +++
Switch 2 UDDDDUDD
Switch 3 DUUDUUUU
MODEM DTE/CLOCK FLOW BUSY DTR
JUMPERS E9-E10 E15-E16 E4-E7 E11-E14
The following is recommended for the ARK 24K Plus Modem:
Switch 1 UUUDDUUU
Switch 2 UDDDDUDD
Switch 3 DUUDUUUU
C.) You can also use the Hayes mode with rings set to zero but you can't
use Doors or SysOp drop to DOS. (This mode has proven to be very reliable)
Parameter 224 Number of rings to wait before answering -------- 0
Parameter 225 Use the RBBS-PC default Hayes commands?--------- NO
1. Reset the modem ------ : ATZ
2. Initialize the modem - : ATM0Q0S2=255S10=30E0S0=1
3,4,5 Use the defaults supplied
Parameter 227 Issue commands between rings ------------------ YES
Parameter 228 Baud rate to initially open modem at --------- 2400
Parameter 237 Leave modem at initial baud rate -------------- NO
Parameter 244 Modem flow control uses Clear-to-Send (CTS) ---- NO
Parameter 245 Modem flow control uses XON/XOFF --------------- NO
The following is recommended for the ARK 24K Modem:
Switch 1 UUUDDUUD (note 8th position)
Switch 2 DDDDDUDD (note 1st position)
Switch 3 DUUDUUUU
MODEM DTE/CLOCK FLOW BUSY DTR
JUMPERS E8-E9 E15-E16 E4-E7 E11-E14
APPENDIX D -- Modems with RBBS-PC D-3
The following is recommended for the ARK 24K Plus Modem:
Switch 1 UUUDDUUD
Switch 2 UDDDDUDD
Switch 3 DUUDUDDD
Technical comments on the Ark Modems for your interest.
1) Ark Modems can't accept any commands if the "AA" (auto answer) light
is on and the phone is ringing until the number of rings equals the
number set in the S0 register. RBBS-PC expects to issue a "modem
answer command" when it detects a ring and is ready. If the Ark modem
can't accept this command, it won't answer the phone. You therefore
cannot use the ring-back system or answer on a ring greater than 1.
2) Another interesting difference is that when the modem is in the "quiet
mode" (Q1) NO results will be sent to the computer. If we inquire as
to the number of rings received, it responds with absolutely nothing.
3) In the Ark Normal mode, if you enter a reset command ATZ or Z, it
requests a confirmation of "Confirm (Y/N) >" and you must enter a Y
or else it does nothing. We can get around this with a ATV0Z which
tricks this into an un-conditional reset.
4) If you attempt to operate in the ARK NORMAL mode at 2400 baud and set
the DTE/CLOCK jumper to E8-E9, the modem will "downshift" to a baud
rate to match the caller, which is normal. Assuming you downshift to
300 baud you must reset it with a ATZ at 300 Baud. RBBS-PC resets it
at the initial rate of 2400 baud and therefore the modem is "hung".
Obviously this is not recommended.
The following modems were tested: 24K - ROM versions 2.21, 2.23, 2.31 24K
PLUS - ROM ver 3.63.
If you have questions on this modem contact:
Dave Hacquebord,
Sunshine Bulletin board,
Tampa, Fl.
Voice: 1-813-884-4267
Data: 1-813-887-3984
Everex Evercom 2400
-------------------
The Everex Evercom 24 is an internal 2400 BAUD modem. It has 4 switches on
the mounting bracket. If you are using COM1 then all switches should be in
the OFF position. If you are using COM2 see the Installation Guide for the
correct switch settings.
The Evercom does not have non-volatile memory like the Hayes 2400 and the
ATZ command will reset the modem to factory defaults. It is therefore not
necessary to use CONFIG to set the Hayes 2400 defaults. Because of this
major difference you must use CONFIG parameter 225 to change the standard
modem defaults. Select parameters 2 and 5 and enter the command just as it
is but with the addition of &D2. This will instruct RBBS-PC to add &D2 to
the standard modem initialization string each time the system recycles.
Please note that although the Evercom 24 manual indicates that &D2 is the
default that this is a misprint in their manual and &D0 is the real default
for the &D command. Parameter 7 can be ignored since they this is for
battery backed up modems only.
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL D-4
NOTE: Make sure that &D2 is inserted immediately following the "AT" when
modifying parameters 2 and 5 of parameter 225!
A special thanks goes to Carl Margolis (Everex) for his help in identifying
these restrictions so that Evercom 24 users can now reliably use RBBS-PC.
Do not select parameter 225 if you are using an Everex 1200 BAUD modem.
FASTCOMM 2496 Turbo Modem
-------------------------
The FASTCOMM 2496 9600 and 19200 baud modems work with RBBS-PC without
modifications to RBBS-PC. However some unusual quirks were noted with the
FASTCOMM hardware. The modems would NOT follow terminal baud rate in the
command mode if the transition was from 300 to 9600 (or 19,200) baud.
Therefore, if RBBS-PC were configured to initially operate at 9600 baud, it
would not properly reset after a 300 baud call. It would, however, follow
all other changes within the range of RBBS-PC. If it was configured to
initially answer at both 2400 and 4800 baud and it worked equally well with
calls at 300, 1200, 2400, 4800, 9600 and 19200 baud for both cases.
Therefore set CONFIG parameter 208 to 2400 baud!
It is recommended that CONFIG parameter 224 be set to answer on one ring!
Specific instructions for modem set up are as follows:
1) Using the BASIC program SETFC.BAS below, set the default modem
settings. This can also be done manually from a communications
program. The speed that is used to establish the default modem
settings is the speed to which the modem defaults on reset and power
on. It is best to do this setup at the same speed that RBBS-PC uses
as its default speed, namely 2400 baud. In any case do not do it at
9600 baud.
2) Tell RBBS-PC to open the modem at 2400 baud by setting CONFIG
parameter 208 to 2400 baud.
3) Use CONFIG parameter 225 to change the modem reset command from "ATZ"
to "AAATZ".
This string of A's resets the modem to the terminal baud rate so it can
respond to the other commands. If you want to experiment, watch the modem
respond to you when you change baud rates in your favorite communications
program. This modem function is referred to as "autobaud". You will
probably not see the first "A" echo and sometimes not the second. You
should always see the third "A". Others have advised that their modems
would "autobaud" from 300 to 9600 baud. Mine would not.
4) Use CONFIG parameter 225 to change the modem answer string to include
X2 instead of X1 (the CONFIG default).
Stan Staten has extensive experience with RBBS-PC and the FASTCOMM 2496
modems. If you have any questions regarding their use with RBBS-PC, give
Stan's RBBS-PC system a call at (301) 869-7650.
The following is STAN's SETFC.BAS program's BASIC source code to set the
FASTCOMM modem. It can be run under the BASIC interpreter or can be
compiled using QuickBASIC from Microsoft. SETFC.EXE and SETFC2.EXE (for
COM2:) can be downloaded from Stan's BBS.
APPENDIX D -- Modems with RBBS-PC D-5
10 'title: 'SETFC.BAS, Copyright 1986 by H. Stanley Staten
20 'SysOp 3 WINKs BBS, 301-670-9621
30 '
40 DEFINT A-Z
50 CLEAR
60 '
70 ' ********************************************************************
80 ' * ROUTINE TO INITIALIZE THE FASTCOMM 2496 MODEM'S FIRMWARE *
90 ' ********************************************************************
100 '
110 COM.PORT$ = "COM1" 'Change to "COM2:" for COM2: use
120 PRINT "Setting FASTCOMM 2496 firmware for RBBS-PC on " + COM.PORT$
130 '
140 ' ********************************************************************
150 ' * *
160 ' * INITIALIZE THE FASTCOMM 2496 VOLATILE MEMORY. SET as follows *
170 ' * *
180 ' * AT#F = Set to factory defaults *
190 ' * AT#LCN = Set carrier detect to normal *
200 ' * AT#LDN = Set DTR to normal *
210 ' * AT#LX2 = Set for XON/XOFF flow control *
220 ' * ATS7=30 = Set wait for answer tone to 30 seconds *
230 ' * ATM0 = Turn speaker off *
240 ' * ATV1 = Issue long form of results codes *
250 ' * ATX2 = Full result messages *
260 ' * ATS57=1 = Hang up and reset automatically executed *
270 ' * ATE0 = Do not echo modem commands back to the PC *
280 ' * ATS10=10 = To cause to reset on loss of carrier faster *
290 ' * ATS58=3 = Force a 19200 Baud call to 9600 Baud locally*
300 ' * ATS22=46 = Suggested by the vendor *
310 ' * ATS0=0 = Don't answer until told to. *
320 ' * AT#W = Write settings to non volatile memory *
330 ' * *
340 ' ********************************************************************
350 '
360 OPEN COM.PORT$ + ":2400,N,8,1,RS,CD,DS" AS #3
370 PRINT #3,"AAAAAAAT"
380 PRINT #3,"AT#F"
390 PRINT #3,"AT#LCN"
400 PRINT #3,"AT#LDN"
410 PRINT #3,"AT#LX2"
420 PRINT #3,"ATS7=30"
430 PRINT #3,"ATM0"
440 PRINT #3,"ATV1"
450 PRINT #3,"ATX2"
460 PRINT #3,"ATS57=1"
470 PRINT #3,"ATE0"
480 PRINT #3,"ATS10=10"
490 PRINT #3,"ATS58=3"
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL D-6
500 PRINT #3,"ATS22=46"
510 PRINT #3,"ATS0=0"
520 PRINT #3,"AT#W"
530 SYSTEM
Leading Edge Series L 2400B Modem
---------------------------------
Gregg Snyder, SysOp of "The Elusive Diamond" - DGS (Alpha) System, and Jim
Thompson of "The Break" -DGS (Delta) System (Data: 703-680-9269) are to be
credited with documenting how to get the Leading Edge Series L 2400B modem
to run with RBBS-PC ("all modems are Hayes-compatible, but some are less
Hayes-compatible than others").
First, you must set CONFIG parameter 228 to open the modem at 1200 baud.
Next, go to CONFIG parameter 225 and set the modem commands as follows:
1. Reset the modem : ATB1H0L1M0C1
2. Initialize the modem : ATH0B1L1M0Q1E0S0=254
Note: End item 2 with:
S0=1Q0X1 if answer on 0 rings
S0=254 if answer on >0 rings (no ring-back)
S0=255 if answer on >0 rings (with ring-back)
3. Count the number of rings : ATS1?
4. Answer the phone : ATQ0X1V1A
5. Take the phone off the hook : ATH1L1M0
6. Clear the modem's firmware : AT&F
7. Initialize modem's firmware : AT&C1&D3B1E0V1M0S0=0&T5
Note: End item 7 with:
Q1 if item 2 ends with S0=255
8. Write to modem's firmware : &W
These settings have been tested for more than a year by Jim Thompson
beginning with RBBS-PC 15.1C.
MICROCOM AX\9624c
-----------------
First set the Microcom AX\9624c switch settings as follows:
CONFIGURATION SWITCH SETTINGS FOR THE MICROCOM AX\9624c MODEM
=============================================================
1 2 3 4 5 6 7 8 9 10
--------------------------------------
Front Switch - U D D D D U U D U U
Rear Switch - U U D U D D D D - -
Change CONFIG parameter 228 to open the modem initially for 9600 baud.
Then go to CONFIG parameter 225 and change some of the default Hayes
commands.
APPENDIX D -- Modems with RBBS-PC D-7
Within parameter 225, you will want to change the second command,
"Initialize the modem." If you want RBBS-PC to answer on one ring set it
to:
ATM0Q1S2=255S10=45E0S0=254&D2
To answer on zero rings, set it to:
ATM0Q1S2=255S10=15E0S0=0Q0X1&D3
Please note that these change the default Hayes commands supplied with
RBBS-PC for S10. Also note that an &D command was added to the end. If
you are set up to answer on ring zero and your modem sometimes stops
answering for no reason that you can isolate, alter the S10 value to "45"
and &D2. You may also want to activate CONFIG parameter 236 to "wake up"
the modem.
These configurations will allow RBBS-PC to establish a MNP reliable or
non-reliable connection from 300 to 9600 BAUD using the AX\9624c's MNP
class 6 Universal Link Negotiation capability.
Prometheus 2400G
----------------
Underneath the 2400G is a bank of 10 switches that set certain operating
characteristics of the ProModem 2400G. Only 3 (1,2 & 10) of these switches
are currently implemented. The others are reserved for future expansion.
All three of these switches must be in the off position for the 2400G to
function properly with RBBS-PC.
USRobotics Courier and HST
--------------------------
Both the US Robotics COURIER 2400 and COURIER HST modem switch settings
should be as follows:
1 2 3 4 5 6 7 8 9 10 gang switch
U U U D D U U D D D UUU (Where U = Up = Off and D = Down = On)
The Courier 2400 is a high quality, trouble free modem that is highly
recommended and which works well with all the RBBS-PC defaults.
The USR COURIER HST modem switch setting should be as follows:
1 2 3 4 5 6 7 8 9 10 gang switch
U U U D D U U D D U UUU (Where U = Up = Off and D = Down = On)
RBBS-PC supports both modes of the USR HST Modems. In CONFIG, specify the
number of seconds between modem commands to be 1.
MODE 1:
-------
In the first mode of operation, CONFIG parameter 228 should be set to the
highest speed you intend to support. When the HST modem detects a carrier,
it sends (at the baud rate set in parameter 228) an ASCII string to RBBS-PC
which contains the new BAUD rate. The modem will change it's baud rate to
match that of the caller's and RBBS-PC will correctly adjust to the modem's
new baud rate. The following CONFIG parameters should be set:
Parameter 222 -- set to 3 to allow the modem enough time to initialize
Parameter 223 -- set to 2
Parameter 227 -- set to NO
Parameter 228 -- set to 9600
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL D-8
Parameter 237 -- set to NO
Parameter 244 -- set to YES
Parameter 245 -- set to NO
You should also reply "NO" to parameter 225, CONFIG will show you a menu of
8 different modem commands. The ONLY command that needs to be changed is
number 7, "Initialize the modem firmware". It should be:
AT&A1&B0&H1&I0&M4&N0&R2&S1&Y3
The meaning of this HST-specific initialization string is as follows:
&A1 = Display/ARQ result codes
&B0 = DTE/DCE rate follows connection rate
&H1 = Hardware (Clear To Send, Pin 5) flow control
&I0 = Flow control disabled
&M4 = Normal if ARQ connection cannot be made
&N0 = Negotiate highest possible link rate with remote modem
&R2 = Received data output to terminal on Request to Send high (Pin 4)
NOTE: If your HST 9600 modem responds 961 or greater to the ATI
command, substitute &R1 for &R2.
&S1 = Modem controls Data Set Ready
&Y3 = Nondestructive, unexpedited break signal
The highest effective data transmission rate in this mode is 9600 baud.
MODE 2:
-------
In this second mode the USR Modem supports the MNP data compression
technique which effectively transmits data over the phone at rates in
excess of 17K baud. Setting up your HST to support both the standard 300,
1200, 2400, and the higher 9600 and 17K baud rates requires that the HST
modem speed be "fixed" at 19.2K baud. The PC running RBBS-PC will
communicate with the HST modem attached to it at a fixed rate of 19.2KB.
The actual data link speed will default to the highest rate that the
caller's modem will support.
Parameter 222 -- set to 3 to allow the modem enough time to initialize
Parameter 223 -- set to 2
Parameter 227 -- set to NO
Parameter 228 -- set to 19200
Parameter 237 -- set to YES
Parameter 244 -- set to YES
Parameter 245 -- set to NO
You should also reply "NO" to parameter 225, CONFIG will show you a menu of
8 different modem commands. The ONLY command that needs to be changed is
number 7, "Initialize the modem firmware". It should be:
AT&A1&B1&H1&I0&M4&N0&R2&S1&Y3
The meaning of this HST-specific initialization string is as follows:
&A1 = Display/ARQ result codes
&B1 = DTE/DCE rate is fixed at allowable rate
&H1 = Hardware (Clear To Send, Pin 5) flow control
&I0 = Flow control disabled
&M4 = Normal if ARQ connection cannot be made
&N0 = Negotiate highest possible link rate with remote modem
&R2 = Received data output to terminal on Request to Send high (Pin 4)
NOTE: If your HST 9600 modem responds 961 or greater to the ATI
APPENDIX D -- Modems with RBBS-PC D-9
command, substitute &R1 for &R2.
&S1 = Modem controls Data Set Ready
&Y3 = Nondestructive, unexpedited break signal
This will enable the COURIER HST to use the built-in MNP protocol at the
highest possible baud rate that can be negotiated with the calling modem --
providing the calling modem is also a COURIER HST modem. The highest
effective data transmission rate in this mode is 17200 baud.
After replying NO to CONFIG parameter 225 and changing the initialization
modem command as described above for either MODE 1 or MODE 2 for the
COURIER HST, CONFIG parameter 231 should be selected in order to initialize
the COURIER HST. This places the setting in the HST's non-volatile random
access memory (NVRAM) and need only be repeated if the NVRAM is changed
(i.e. you use the modem with applications other than RBBS-PC that change
the NVRAM).
For the COURIER 2400, set CONFIG parameter 228 to 2400. For the COURIER
HST, set parameter 228 as specified above for either MODE 1 or MODE 2.
USRobotics HST Dual Standard
----------------------------
The USRobotics Dual Standard is an excellent choice for BBS SysOps. It
combines reliability, performance and compatibility. The biggest hurdle is
the price! However, SysOps can contact USRobotics at (800) DIAL-USR for
information about SysOp special prices.
The Dual Standard can support low-speed connections, as well as V.32, V.42,
V.42bis and HST-mode connections. A proper configuration of the BBS modem
will allow a caller with nearly ANY modem to connect with your BBS.
The file MODEMS.SET contains proper switch settings, firmware and
initialization settings, and CONFIG parameter settings for the dual
standard. However, you should consider the following:
1) The dual standard is flexible. The configuration suggested for
RBBS-PC will allow nearly all modems to connect to your BBS, but
perhaps not at the optimum speed. The main consideration for
performance is the use of data compression. RBBS-PC will ENABLE
data compression on your modem. If your callers also enable
compression, V.32 throughput when transferring COMPRESSED files
will suffer. However, throughput when capturing large text files
(such as reading messages non-stop) will be much higher than
normal. You may want to post a bulletin to your users that if
they want FAST FILE TRANSFER, they should DISABLE compression
(&K0 is the modem command for the dual standard). If they do so,
your modem will also disable compression for their call. This
will allow each caller to decide if they want maximum throughput
for compressed files, or for text files.
2) For best results, the baud rate is locked between RBBS-PC and the
modem. This allows the modem to negotiate speed with the caller, but
RBBS-PC can transfer data as fast as possible. This should work under
all instances, but if you have trouble configuring doors or external
protocols, you may wish to turn off this feature. To do this, change
the baud lock command in the FIRMWARE initialize command (CONFIG
parameter 225) to ???, and tell RBBS-PC to NOT remain at the initial
baud rate (CONFIG parameter ???).
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL D-10
ZOOM Modem HC2400
-----------------
In order to use the "ZOOM HC2400" modem with RBBS-PC parameter 225 should
be changed as shown below. Only #2 and #5 need to be changed.
Changes in #2. Add '&D2' just after 'AT'. Change 'S2=255' to 'S2=43'.
Change in #5. Add "&D2' just after 'AT'.
1. Reset the modem : ATZ
2. Initialize the modem : AT&D2M0Q1S2=43S10=30E0Q0X1S0=0
Note: End item 2 with:
S0=1Q0X1 if answer on 0 rings
S0=254 if answer on >0 rings (no ring-back)
S0=255 if answer on >0 rings (with ring-back)
3. Count the number of rings : ATS1?
4. Answer the phone : ATQ0X1V1A
5. Take the phone off the hook : AT&D2Q1E1H1M0
6. Clear the modem's firmware : AT&F
7. Initialize modem's firmware : AT&C1&D3B1E0V1M0S0=0&T5
Note: End item 7 with:
Q1 if item 2 ends with S0=255
8. Write to modem's firmware : &W
For further information contact:
Jeff L. Watts
STATESVILLERBBS-PC Data # (704) 873-8482
APPENDIX E -- RBBS-PC and the Hearing-Impaired E-1
APPENDIX E -- RBBS-PC and the Hearing-Impaired
----------------------------------------------
Telecommunications Devices for the Deaf (TDDs) use the Baudot character set
(i.e. 5-bit) and utilize modems that transmit at 45 baud and do not
generate a carrier signal. This is because such devices were initially
adaptations of surplus Western Union TTY machines for telephone
communications. The widespread use of Baudot devices by the hearing-
impaired, the previous high cost of computers and modems, and the lack of
software designed for electronic communications, has impeded the change to
ASCII communications by the hearing-impaired community.
Equipment manufacturers have also made it difficult for the deaf to change.
When TDD's with ASCII code transmission capability began to be offered, the
majority of manufacturers limited them to only 110 baud and put disclaimers
in their manuals that said ASCII was available for use but that "computer
language" was "less reliable" and hard to use. Their limiting of the TDD's
output screen to 12 to 20 characters further compounded the problem because
the screen would overwrite several times to display one line of text from a
host system. The manufacturers' "solution" to this problem was to
recommend printers for communication with such "host" systems as RBBS-PC.
Some units now offer both 110 and 300 baud ASCII transmission in addition
to the 45 baud Baudot. Unfortunately, these typically have only 20
character screens.
In December of 1984, Ted Janossy of Rochester, Minnesota, sent a three-page
letter to Tom Mack describing the above situation. Ted's letter motivated
Tom to test and verify the "ring-back" feature of RBBS-PC in 12.4A. It
had not been tested in earlier versions because Tom assumed (presumptuously
and insensitively) that "real SysOps don't use ring-back RBBS-PC's." Ted's
letter awakened Tom to the potential of RBBS-PC to facilitate
communications among the hearing-impaired. In the awakening, Tom also had
a chance to look down at his own feet of clay.
RBBS-PC can be configured to answer calls only after a specified number of
rings (i.e. 15). The telephone companies wire the homes of the
hearing-impaired such that when the phone rings, the lights within the
house flash on and off.
With RBBS-PC a SysOp can specify the number of rings RBBS-PC is to wait
before answering the phone automatically. Setting this number high enough
allows someone with a hearing impairment time enough to get to the PC
running RBBS-PC. Pressing the PC's function key 5 (F5) causes RBBS-PC to
answer the phone immediately. The caller would know that someone was at
the keyboard because RBBS-PC answered the phone in less than the agreed-
upon number of rings. The caller would log onto RBBS-PC normally and the
person at the PC keyboard would be able to see who it was. If the person
who was called wanted to "chat" with the caller, all they would have to do
would be to press function key 10 (F10).
If RBBS-PC didn't answer the telephone within the agreed-upon number of
rings, the caller would know that whomever was being called couldn't come
to the keyboard. The caller would then log on and leave a message.
APPENDIX F -- RBBS-PC And The AT's RS-232 Cable F-1
APPENDIX F -- RBBS-PC And The AT's RS-232 Cable
-----------------------------------------------
The RS-232 serial connector is different for the AT than the PC or XT. The
AT uses a connector called a DB-9, which is a 9 pin connector. An
alternative to buying the AT serial cable from IBM, ($65-$80), is to make
your own. A ten-wire cable can be purchased from any local computer store
for about $.80 per foot, and the DB-9 and RS-232 connectors with hoods can
be purchased from Radio Shack. The total cost should be about $12.00. A
modem hooked up to the AT will work fine with the 9 pins connected in all
terminal functions, except for auto-answer applications such as RBBS-PC.
RBBS-PC requires pin 1 from the modem to be hooked up to the chassis ground
on the AT or it can't answer the phone. There are two ways to hook up the
ground wire on the computer end. The first way is to use a metal hood to
cover the DB-9 connector. Wrap a bare wire that is attached to pin 1 of
the RS-232 connector around the cable on the DB-9 end. When the metal hood
is screwed down over the cable a connection will be made. When using a
plastic DB-9 hood simply solder a wire from pin 1 on the RS-232 end to the
metal body of the DB-9 connector. Since documentation is scarce for the
AT, following figure lists the necessary pin connections for those wanting
to make their own AT RS-232 cable.
DB-9 RS-230
(Computer (Modem Description
End) End)
========= ======= ==================
GROUND -------- 1 -------- Protective Ground
1 -------- 8 -------- Data Carrier Detect
2 -------- 3 -------- Receive Data
3 -------- 2 -------- Transmit Data
4 ------- 20 -------- Data Terminal Ready
5 -------- 7 -------- Signal Ground
6 -------- 6 -------- Data Set Ready
7 -------- 4 -------- Request to Send
8 -------- 5 -------- Clear to Send
9 ------- 22 -------- Ring Indicator
APPENDIX G -- RBBS-PC And BASIC Compiler Patches for "Doors" G-1
APPENDIX G -- RBBS-PC And BASIC Compiler Patches for "Doors"
------------------------------------------------------------
A bug in Microsoft's BASIC and QuickBASIC compilers requires SysOps who
wish to recompile RBBS-PC to apply the following patches. The problem has
to do with BASIC's treatment of the communications port when you exit a
BASIC program. The Data Terminal Ready (DTR) line MUST be kept on at all
times, or the modem will hang up on your caller.
If you are recompiling RBBS-PC, and you plan to use Doors or external
protocols, you must make the following patches. Any hex editor can be
used: DEBUG, which comes with DOS, or the Norton Utilities are just two
examples. A tutorial on how to use DEBUG is beyond the scope of this
document.
There are actually two patches, depending on the version of the compiler
you have. The first patch is for QuickBASIC 2, 3 & 4 or BASCOM 6.0.
The file you will patch is BCOMx0.LIB (where X is the QB version number).
Of course, you will save your original file before applying the patch. To
make the fix, you will search for the following string of HEX digits: 83 C2
04 32 C0 EE. The assembly code for this string is:
83 C2 04 ADD DX,4
32 C0 XOR AL,AL
EE OUT DX,AL
We need to change the XOR AL,AL to MOV AL,1. Change the "32 C0" to "B0
01". Make this change in both places where the string occurs.
If you use QB 4.5, or BASCOM 7.0, the patch is different. Look for the
string: B0 00 E3 01 40 83 C2 04 EE. In assembly code, it is:
B0 00 MOV AL,00
E3 01 JCXZ nnnn
40 INC AX
83 C2 04 ADD DX,4
EE OUT DX,AL
Again, we want to put a 1 in AL, so we change the "B0 00" to B0 01". We
also need to remove the INC AX, so change the "40" to "90".
You may also want to make an additional patch. This patch will prevent
QuickBASIC from pausing on a fatal error. Normally, BASIC says "press a
key to continue". If RBBS-PC were allowed to recycle, it would do so
without trouble, but BASIC will hold up your board until you press a key.
If you have QuickBASIC 2.01 or 3.0, search the BCOMx0.LIB for the following
string of HEX digits: E2 F8 E8 00 00 E8 00 00 E8 00 00 C3. Change the
MIDDLE "E8 00 00" to "C3 90 90". If you have QuickBASIC 4.5, search for
the string "B8 07 0C CD 21" and change the "CD 21" to "90 90". Now,
whenever BASIC can't handle an error, it will allow RBBS-PC to recycle
quickly.
If you have BASCOM 7.0, you can apply the patch for QB 4.5, although you
will have to patch whichever BC70xxxx.LIB file you use to link.
Thanks to Doug Azzarito, Jeff Porter, Rod Bowman, Kenny Gardner and Bob
Eyer for information on these patches.
APPENDIX H -- Running a multiple node RBBS-PC H-1
APPENDIX H -- Running a multiple node RBBS-PC
---------------------------------------------
Before you consider running multiple nodes (i.e. allowing more than one
caller on your BBS at a time), you should already have RBBS-PC working well
on one node. If you don't have your board running smoothly with NO
crashes, STOP right here and concentrate on your single-node system. You
will only compound your errors and frustrate yourself if you try to get
RBBS-PC operating on multiple nodes before you get it operating well on one
node.
When configuring a multi-node RBBS-PC, you may have to make a decision of
SPEED vs. STORAGE. In a LAN environment, accessing data stored on another
machine is slow. Therefore, you may want to keep copies of ALL text files
on each machine, and ONLY share those files that are mandatory (MESSAGE,
USER, UPLOAD dirs). However, to do this you will have to keep nearly ALL
RBBS-PC files updated on EACH RBBS-PC machine. This can waste storage,
increase maintenance hassles, but it does greatly improve performance on a
LAN. Other single-machine environments (such as DESQview, PC-Slaves) do
not require you to make this choice.
To make multi-node operation easier, you may want to put all "node-
specific" files in separate directories (i.e. C:\RBBS\NODE1, C:\RBBS\NODE2,
etc.). This will reduce the chances of having one node overwrite a file
from another node. The following example assumes you have created a NODE
subdirectory for each node on your system.
There are certain parameters in the CONFIG utility which you will want to
consider adjusting in order to facilitate your multi-node RBBS-PC.
To begin with, you will need to make an CONFIG .DEF description file for
each node. Copy the file RBBS-PC.DEF to RBBSnPC.DEF, where "n" is the
number for the node (e.g. RBBS1PC.DEF, RBBS2PC.DEF, etc.). You will need a
configuration description files for each node, even if it is a "local" node
without a modem.
When you start the CONFIG utility, you can either specify the configuration
description file name after the CONFIG program name on the command line
(e.g. CONFIG RBBS1PC.DEF), or you can let CONFIG ask you whether you will
be running multiple RBBS-PCs, answer the question with "Y", and then
specify the number of the node you wish to edit (answering "1" at this
point would then edit RBBS1PC.DEF).
The CONFIG parameters that you will probably want to change in your multi-
node system are as follows:
161 Maximum number of concurrent RBBS-PC's. Set this to the maximum
number of nodes you will ever run. Remember that you need to allocate
space for your local nodes, also. This causes more space to be
allocated in the MESSAGE files. You can change this number at any
time, and CONFIG will create the needed room, however the only harm in
allocating EXTRA nodes is 128 bytes of wasted disk space per node.
162 Environment running multiple copies. Select whichever network type
describes the environment you are running. If you have some doubt as
to which type fits your network, select NETBIOS (DOS SHARE). NETBIOS
is a fairly universal network interface for applications software, and
most LAN products offer support for it.
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL H-2
88 System file for recording comments. You can set a different comments
file for each node you are running (NODE1\COMMENTS and NODE2\COMMENTS,
for example), but RBBS-PC can allow a single, shared comments file in
all but the CORVUS network.
90 Caller log files. RBBS-PC does NOT share log files between nodes.
Each node must have a separate log file (NODE1\CALLERS, etc). If all
nodes write to the same callers file, you will not be able to figure
out which node did what!
93 File controlling scan for mail waiting. If, for some reason, you want
to have some conferences or sub-boards visible on only one of your
nodes, you have the option of creating separate conference mail
control files (e.g. NODE1\CONFMAIL.DEF, NODE2\CONFMAIL.DEF, etc.)
This is certainly not required, however, and most installations will
run with identical conference mail control files.
100 File built dynamically to open a door. RBBS-PC creates an batch file
for each node when dooring. This batch file must be unique for the
node. Name yours NODEn\RCTTY.BAT, where "n" represents the node you
are configuring currently.
104 The .BAT file to re-invoke RBBS-PC. If you do not make your RBBS.BAT
file read-only, you might have problems when several nodes attempt to
access it at the same time. In most cases, this can be avoided by
marking the .BAT file "READ ONLY," but you may have to have a unique
BAT file for each node of RBBS-PC (e.g. RBBS1.BAT, RBBS2.BAT, etc.)
204 Drives available for downloading. Make certain to list not only the
drives from the computer local to the node, but also the network drive
letters. We recommend using the DOS SUBST command to make the
references to local drives match those that the remote machine refers
to them as. For example, if the remote machine refers to your drive
C: as drive W:, then use the DOS SUBST command and refer to it locally
as drive W:, also. It will reduce confusion for you to only refer to
a drive by one name. Remember, you can have up to 15 letters, no
more.
Now save these CONFIG parameters, and you will have a "network ready"
configuration description file. You can copy this .DEF file for the other
nodes, and then change the node-specific parameters for each. Remember,
each node gets its OWN file!
Remember also that each node is likely to have a different modem. Not in
ALL cases, obviously, but it justifies a reminder here. Let's take a
typical example. On one node, you are using a Hayes 2400 compatible modem,
and on the other a US Robotics Courier HST. Obviously, the setup is
greatly different between these two. It's not a problem with RBBS-PC,
however. When you have CONFIG loaded and are editing the node's
configuration description files just remember to put the proper information
FOR THAT NODE into CONFIG parameters 221 (Comm port), 225 (Modem settings)
and 231 (Firmware initialization). Each node can have a different modem,
use a different COM port, run at different speeds, or even use a FOSSIL
driver or not, and RBBS-PC can easily adjust to it.
AUTOEXEC.BAT
In the AUTOEXEC.BAT file for each node, you will want to add the following
environment variables.
APPENDIX H -- Running a multiple node RBBS-PC H-3
SET NODE=n (where "n" is the node number)
SET DSZLOG=XFER-%node%.DEF
There may be other variables also required by your individual setup, but
the RBBS.BAT file expects to find the %node% variable, and some external
file transfer protocol drivers (DSZ, especially) will use the DSZLOG file
to pass success-or-fail back to RBBS-PC. You need a separate one built for
each node, and this will take care of it.
SUB-BOARDS
If you have sub-boards set up, you will create a configuration description
file for each sub-board. However, the configuration description file will
not have a node number in its title. The configuration description file
name will take the form "xxxxxxxC.DEF", where "xxxxxxx" is the 1-7
character sub-board name. For example, a sub-board named GAMES would have
a configuration description file named GAMESC.DEF. This is a major
difference from the configuration description file for the nodes
themselves. Each node has its own file, because each node is completely
different (usually). But with a sub-board, parameters about the modem,
etc., are not needed. Therefore, there is only ONE configuration
description file for each sub-board.
RBBS-PC will search for a conference .DEF file in THREE places (and in the
following order):3
- The default drive/path (when RBBS-PC starts)
- The location of the CURRENT message base (the one active when the JOIN
command is used).
- Where the CONFERENCE menu file is stored (see CONFIG parameter 74).
Here's an important tip to help with sub-boards functioning on multiple
nodes. CONFIG parameter 90 controls the system callers file. Select this
parameter, and when CONFIG asks you if you want to have a callers file,
answer "N". This will cause the sub-board to use the same callers file
that the node is currently using. Since you only have one configuration
description for each sub-board, specifying a callers file in the sub-board
configuration description file would cause information from both nodes to
be written to the same callers file, and this would be mass confusion.
DOORS
Many door programs (especially older ones) are simply not network
compatible. Some of the doors that you have been running for years will
suddenly not work in a network. Each door is an individual case. Some
doors are hard-coded to pick up DORINFO1.DEF and cannot be made to read
DORINFO2.DEF. Others are locked into COM1 and cannot be forced over to
COM2. And still others force you to have DORINFO1.DEF in a directory
called "C:\RBBS" and will refuse to look anywhere else for the possibility
of a second node's files.
When you have a door which is network compatible, usually the documentation
that accompanies the program will explain in detail how to install the door
on your BBS. In general, a door program is installed in one location on
the network, and all nodes will run the door from that subdirectory.
RBBS-PC will create a DORINFOn.DEF, where "n" is the node number, when it
exits to a door. Almost all door programs want to know where this file is,
and a variety of options are available to you. One option often used is to
set an environment variable to the drive letter that will be the default
drive for a specific node.
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL H-4
For example, let's say that our Node 1 system runs from W:\RBBS, and our
Node 2 system runs from Y:\RBBS. If we set an environment variable in each
node's AUTOEXEC.BAT file called RBBS (e.g. SET RBBS=W:), then we can refer
to the location of the DORINFOn.DEF file as:
"%rbbs%\RBBS\DORINFO%node%.DEF".
(Notice the use of the %node% environment variable, also.) In this way,
each node running the door will substitute the proper drive and node number
to the door.
MISCELLANEOUS TRICKS
RBBS-PC is written to share resources with no conflict between nodes. For
example, both nodes will access the same message and user files, and at the
same time. Under ordinary DOS circumstances, this would cause a "sharing
violation" error. RBBS-PC, however, accesses files in "shared mode", which
eliminates this error. There are still times, however, when files are
accessed outside the direct control of RBBS-PC. To eliminate the
possibility of sharing violation errors at these times also, we recommend
marking all your TEXT, .COM, .EXE, and .BAT files "read only". (The read
only attribute lets DOS know that it's okay for more than one process to
access this file at the same time, because NEITHER process will be able to
modify it.)
To change a file's attribute, you will use the DOS utility ATTRIB. The
command syntax is "ATTRIB +R filespec", where filespec can be anything up
to and including "*.*". Conversely, "ATTRIB -R filespec" will remove the
read only attribute so that the file may be changed.
If you are operating your multi-node RBBS-PC with two separate RBBS-PC
subdirectories (i.e. all files duplicated in a second location except those
which MUST be shared), then this precaution is not needed. If, on the
other hand, you are operating your multi-node RBBS-PC with a SINGLE RBBS-PC
subdirectory, then we recommend making all files read-only which will not
be written to by RBBS-PC.
Files which will be written to are the callers files, the user files, the
message files and the upload directory. Since these are only opened from
within the RBBS-PC program, you will not have sharing problems here.
(Note: Some door programs require access to these dynamic files, and do
not support shared access. This can cause the door program to malfunction.
This would be considered a door program which is NOT "network-able".)
APPENDIX I -- RBBS-PC in a DESQview Environment I-1
APPENDIX I -- RBBS-PC in a DESQview Environment
-----------------------------------------------
DESQview, from Quarterdeck Office Systems, provides an excellent, low-cost,
software platform for RBBS-PC SysOps wanting multiple nodes on a single PC.
This appendix has been provided to help both the novice SysOp and the more
experienced SysOp with the implementation of multiple nodes under DESQview.
1. Basic Hardware Considerations
--------------------------------
If your computer has only 640k, you will be limited to a single node when
using DESQview. If, however, your computer has 1-Megabyte or more of EEMS
memory, DESQview is capable of supporting up to 8-nodes on a single
computer. Providing two nodes is simple. Going beyond two nodes will
require special software and hardware. This appendix describes both
approaches.
Multiple-node operation will require an EEMS-compatible memory expansion
card for your computer. Make certain your memory card is EEMS (not merely
EMS, but EEMS) compatible! If you are not using an 80386 computer,
DESQview can ONLY swap EEMS memory, so you will want to replace as much
motherboard memory as possible with EEMS RAM. This limitation is described
in the DESQview documentation. These limitations do not apply if you use
an 80386/SX or 80386 based computer. Therefore, we recommend an 80386 as
the best choice for a multi-node host computer. If you plan to use an
80386 or 80386/SX computer, we suggest you purchase DESQview/386, which
includes the QEMM memory manager. This memory manager allows DESQview to
use regular 80386 Extended memory in the same manner as EEMS memory. The
QEMM memory manager may be purchased separately if you already have
DESQview.
Before you continue, make certain you have read and thoroughly understand
the instruction manual provided with your copy of DESQview.
2. Modifications to DOS CONFIG.SYS and RBBS-PC batch files
-----------------------------------------------------------
The first step in using DESQview with RBBS-PC is setting up your CONFIG.SYS
file. The FILES statement is critical. Allocate at least 16 files for
each copy of RBBS-PC. QEMM/386 will allow you to allocate files without
using base RAM (see the QEMM manual for details). Increasing DOS BUFFERS
will also help, but options such as a disk CACHE will determine the optimum
setting.
A 2-node CONFIG.SYS file should include the following:
FILES=32
BUFFERS=25
You should start RBBS-PC from a two-level batch file. A "startup" batch
file will perform functions required only once, when you open the DV
window. The second file, RBBS.BAT, will start RBBS-PC, and process the
recycling, doors and daily maintenance.
In our example, the "startup" batch file is named START.BAT. The node
number for each RBBS-PC node is passed to START.BAT by DESQview. In so
doing, you only need to provide a .DVP file for each node. All the batch
files are the same, which reduces confusion and maintenance.
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL I-2
in C:\RBBS\START.BAT Description of each line's function:
-------------------------- --------------------------------------
DVANSI loads DESQview ANSI.SYS driver
SET NODE=%1 Sets the node number for this RBBS-PC node
LDFILTER.COM explained later in this appendix
SET DSZLOG=XFER-%node%.DEF set DOS environment variable for DSZ
RBBS call RBBS.BAT
The standard RBBS.BAT (explained in section 13) will be adequate for use
with each node of RBBS-PC under DESQview.
3. What to Tell RBBS-PC's "CONFIG" Utility
------------------------------------------
When using DESQview, you will need to change some parameters with the
CONFIG program (supplied with RBBS-PC). If you are running only one node,
the only required change is parameter 162 (network environment). Set this
to DESQview. If you are running multiple nodes, consult appendix G for the
parameters that should be set to properly configure multiple nodes.
4. DESQview Setup Default Settings
-----------------------------------
The next step in configuring DESQview for use with RBBS-PC is specifying
the default settings for DESQview. DESQview has a setup program that may
be invoked at the DOS prompt. Enter SETUP to run this DESQview setup
routine. After the SETUP program loads, press RETURN for the Advanced Setup
Procedure followed by a "P" for Performance defaults. Here is an example
of the recommended settings:
------------------------------------------
I Task Processing Time (in Clock Ticks) I Optimum Fore/Backgrnd can vary
I Foreground: 9 I between 15/14 and 4/3. These
I Background: 8 I settings will vary depending on
I I CPU speed and number of nodes
I Memory Usage (in K) I in operation. Experiment with
I Common Memory: 24 I different settings to find the
I DOS Buffer for EMS: 2 I best for your system.
I I
I Optimize communications? (Y/N): N I Select [Y] if you're operating
I Allow swapping of programs? (Y/N): Y I only 1-node under DESQview!
I Manage printer contention? (Y/N): N I
I I
I Next field Tab I
I Backup menu Esc I
I DONE <─┘ I
I I
------------------------------------------
NEVER indicate more clock ticks for Background processing than you are
using for the Foreground processing. DESQview will automatically increase
the amount of Background clock ticks whenever there is little demand for
Foreground processing. This will be the case when running RBBS-PC in the
background and doing word processing or a similar task in the foreground.
This feature cannot function properly if the Background clock ticks are set
higher than the Foreground clock ticks. Setting the High Speed Comm
default to YES will make communications interrupts the highest priority.
While this is suggested if you operate a single node, you should specify NO
for optimum performance when operating multiple nodes.
APPENDIX I -- RBBS-PC in a DESQview Environment I-3
5. Adding RBBS-PC to DESQview's "Open Window" Menu
---------------------------------------------------
Refer to the section "Adding Your Own Program" in the DESQview manual. You
will need to "Add a Program" for each node of RBBS-PC you intend to operate
on your system. You may name the programs N1, N2, etc. N1 will load the
batch file START.BAT with the Parameter "1". N2 will load START.BAT with
the Parameter "2" and so on. Use the following settings for each node (or
copy) of RBBS-PC you install.
Add a Program
--------------------------------------------------------------------------
Program Name............: [NODE-1]
Keys to Use on Open Menu: N1 Memory Size (in K): 380
Program...: START Please note that Memory Size above may
need to be increased if you intend to
Parameters: 1 (node number) SHELL (rather than DOOR) to External
file transfer protocols.
Directory.: C:\RBBS
Options:
Writes text directly to screen.......: [N]
Displays graphics information........: [N]
Virtualize text/graphics (Y,N,T).....: [N]
Uses serial ports (Y,N,1,2)..........: [Y] <-N if Using a
Requires floppy diskette.............: [N] FOSSIL driver
--------------------------------------------------------------------------
Next, press F1 for the Advanced Options menu.
Change a Program Advanced Options
--------------------------------------------------------------------------
System Memory (in K).......: 0 Maximum Program Memory Size (in K)..:
Script Buffer Size.......: 1 Maximum Expanded Memory Size (in K):
Text Pages: 1 Graphics Pages: 0 Initial Mode: Interrupts: 00 to FF
Window Position:
Maximum Height: 25 Starting Height: Starting Row...:
Maximum Width.: 80 Starting Width.: Starting Column:
Shared Program
Pathname..:
Data......:
Close on exit (Y,N,blank)......: [N] Uses its own colors............: [Y]
Allow Close Window command.....: [Y] Runs in background (Y,N,blank).: [Y]
Uses math coprocessor..........: [N] Keyboard conflict (0-4)........: [0]
Share CPU when foreground......: [Y] Share EGA when foregrnd/zoomed.: [Y]
Can be swapped out (Y,N,blank).: [N] Protection level (0-3).........: [0]
--------------------------------------------------------------------------
6. Memory Considerations
------------------------
Please refer to your DESQview documentation for information regarding the
use of XDV.COM and optimizing the size for each DESQview window. Current
versions of DESQview require a little under 180k of your system's memory,
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL I-4
leaving only 430k to operate RBBS-PC on a system with 640k. Specify a
minimum window size of 380k for RBBS-PC. If you choose to SHELL (rather
than DOOR) to external protocol drivers for file transfers, you will have
to increase this window size.
It is necessary to use EEMS memory to run two or more concurrent copies of
RBBS-PC under DESQview. If available EEMS memory allows, you may wish to
add an additional "LOCAL" node for SysOp use. When using an additional
node for SysOp duties, an additional modem and RS-232 interface are not
required. Simply use CONFIG to set up the .DEF file for the node you are
planning to use for SysOp duties. You must specify the communications port
as COM0. Failure to do so will prevent your local SysOp node from loading
properly.
7. Expanded Memory
------------------
If you are using an "Expanded Memory" board that allows more than 640k to
be used for programs, the constraints discussed in the previous section may
not apply. Specify a window size of 460K for each node of RBBS-PC and
invoke the external protocol drivers by SHELLing. For information on
running programs in expanded memory, refer to the manuals for DESQview and
your particular memory board.
8. How to AUTOEXEC RBBS-PC From DESQview
----------------------------------------
Refer to the section "LEARN: DESQview's Keystroke Macro Feature" in the
DESQview manual. A script assigned to the ! key (on the DESQview menu) has
a special meaning. It is performed at the time you start up DESQview,
immediately after the DESQview menu appears. This is called a STARTUP
SCRIPT. You should "Learn" the Startup Script with no windows open and
with the DESQview menu displayed to be sure it will play back properly.
Use this particular script to load N1, N2, etc. of RBBS-PC. If you load
DESQview from your AUTOEXEC.BAT file, RBBS-PC will load from DESQview
automatically. This can be handy if there is a power outage while you are
away and no one is around to re-load RBBS-PC when the electricity returns.
You should open the window(s) for RBBS-PC prior to opening windows for any
other application software.
9. Quarterdeck Utilities
------------------------
Two Quarterdeck utilities, STDERR.COM and LDFILTER.COM are distributed with
RBBS-PC. LDFILTER.COM should be executed when you open a window in
DESQview. If you use the Small & Fast version of RBBS-PC, or you compile
RBBS-PC with QuickBASIC v2.01, you should use LDFILTER.COM. In the above
examples, LDFILTER would be placed into the START.BAT batch file. LDFILTER
was written by Quarterdeck Office Systems to compensate for the memory
mismanagement of the BASIC compilers. If you try to "SHELL" to an external
routine the error "not enough memory to SHELL" is issued. LDFILTER.COM
prevents this error condition by preventing the code generated by the BASIC
compilers from mis-managing memory.
STDERR.COM should be executed from your autoexec.bat file, prior to loading
DESQview. STDERR was written by Quarterdeck Office Systems to compensate
DOS' inability to redirect the standard error output to the same device
that the standard output device had been redirected to. If you are running
something remotely and an error occurs, STDERR.COM allows the error to be
displayed at the remote user's end and not simply on the PC that is running
RBBS-PC under DESQview.
APPENDIX I -- RBBS-PC in a DESQview Environment I-5
10. Redirecting I/O Considerations (DOS CTTY Command)
-----------------------------------------------------
The DOS CTTY command is NOT supported under DESQview. The GATEWAY device
driver version 2.0, by Hans D. Kellner, provides an excellent alternative.
This device driver is available on many bulletin boards under the filename
GATEWAY2.ZIP.
Since the DOS CTTY command is not supported within a DESQview window, you
may use GATEWAY2 to allow redirection of I/O. This will allow the SysOp
Function 7 (drop to DOS) to function properly! It will also allow RBBS-PC
DOORS to function that rely on the CTTY command.
Instructions for installing GATEWAY2 with RBBS-PC.
1) Place the file 'GATEWAY2.SYS' in your boot disk root directory.
2) Add the following lines to your 'CONFIG.SYS' file:
DEVICE=GATEWAY2.SYS -D -1 <-- for node-1 using COM1
DEVICE=GATEWAY2.SYS -D -2 <-- for node-2 using COM2
(note) You must change the [-d] parameter to [-f] if you are using a
FOSSIL driver (described later in this appendix).
3) Run the RBBS-PC CONFIG.EXE program for each node of RBBS-PC you're
using. Select parameter 106, and specify that you do NOT want to
redirect via CTTY. CONFIG will then ask if you wish to redirect via a
device driver. Enter "Y", and then enter GATE2 as the device name.
The use of GATEWAY2 has an added benefit for those SysOps who provide the
PC-SIG collection of files on CD-ROM. When a user A)rchives a disk,
RBBS-PC will use Gateway to redirect the archive activity (normally seen
only on the SysOp's screen) to the remote user. This will allow the caller
to see the PC-SIG disk being archived!
11. FOSSIL Drivers - Break the 2-node Barrier under DESQview!
-------------------------------------------------------------
The BASIC language can only support COM1 and COM2, and when either of these
are selected and you specify that you will not be using a "FOSSIL" driver,
RBBS-PC will use the built-in BASIC support for remote access (i.e. via a
communications port and a modem). However, RBBS-PC will interface with
"FOSSIL" drivers that support not only COM1 and COM2 but also COM3 through
COM8. If you use parameter 221 to indicate that RBBS-PC is to access the
communication port via a FOSSIL driver, the FOSSIL interface (FOSSCOMM.OBJ)
written by Daan Van der Weide will be used. FOSSCOMM is already built into
RBBS-PC, so it will be active as soon as you select it. In a multi-tasking
environment such as DESQview up to 8 copies of RBBS-PC can run
simultaneously accessing COM1 to COM8, respectively, using Ray Gwinn's
X00.SYS device driver. Ray can be reached via FidoNet (109/639) or the
RENEX bulletin board at (703) 494-8331 or (703) 690-7950. X00.SYS is also
available on many BBSs.
When using FOSSIL support, you will select CONFIG parameter 221. After you
specify a communications port, CONFIG will ask if it should use FOSSIL
support. Answer YES, and then enter the base comm port address for the
port. See the chart later in this section for common base port settings.
If you choose to implement a fossil driver, you'll want to change the
following parameter for each DESQview window:
Options:
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL I-6
Uses serial ports (Y,N,1,2)..........: [N] <--Set to NO
If the fossil is handling communications, you should tell DESQview that
RBBS-PC is NOT using serial ports. That way, only the fossil is handling
the communications for each port.
In the following text, we will attempt to give you some basic information
regarding the use of X00.SYS with RBBS-PC. For additional information,
please refer to the documentation provided with the X00.SYS fossil driver.
There are several approaches that can be taken to implement serial ports
with Ray Gwinn's X00.SYS. THE FIRST APPROACH involves the use of separate
base I/O addresses and separate IRQs for each serial port. This is the
method we use on our BBS to provide 4-ports on a single 80386-based
computer. We use the following configuration:
Card #1 COM1 IRQ4 3F8h (standard IRQ, standard base I/O)
Card #1 COM2 IRQ3 2F8h (standard IRQ, standard base I/O)
Card #2 COM3 IRQ7 3E8h (non-standard IRQ, standard base I/O)
Card #2 COM4 IRQ5 2E8h (non-standard IRQ, standard base I/O)
We use serial ports with the NS16550AFN UART chips. This particular chip
is recommended if you intend to use 9600-bps modems with multiple nodes
under DESQview.
Here is a sample CONFIG.SYS line that activates X00.SYS. In addition to
specifying the IRQs and base I/O for each port, each port is locked to
19,200 bps. High speed modems, or ones that use data compression will gain
throughput if the port speed is locked. This is not necessary if you are
using a standard Hayes-compatible 2400-bps modem. This entry is on a
single line but appears as two lines below.
DEVICE=C:\X00.SYS E T=2048 R=2048 0=3F8,IRQ4 1=2F8,IRQ3 2=3E8,IRQ7 3=2E8,
IRQ5 B,0,19200 B,1,19200 B,2,19200 B,3,19200
We have also configured GATEWAY2 (discussed earlier in this text) to make
use of the fossil driver. The lines in CONFIG.SYS would be:
DEVICE=C:\GATEWAY2.SYS -F -1 (gateway for COM1)
DEVICE=C:\GATEWAY2.SYS -F -2 (gateway for COM2)
DEVICE=C:\GATEWAY2.SYS -F -3 (gateway for COM3)
DEVICE=C:\GATEWAY2.SYS -F -4 (gateway for COM4)
THE SECOND APPROACH also involves the use of a separate base I/O for each
port, but IRQs are "shared". Recent versions of X00.SYS will manage the
use of a "Shared" IRQ. For example, COM1 and COM2 on the first serial card
share IRQ4. COM3 and COM4 on the second serial card share IRQ3. Under
this arrangement each port sharing an IRQ must be located on the SAME CARD.
This requirement is not due to X00.SYS but is, instead, a hardware
restriction; IRQs cannot be shared between boards.
In both the above examples, NON-intelligent serial cards are used. RBBS-PC
will NOT support the many "Intelligent" multi-port I/O cards on the market.
These "Intelligent" boards are popular in other environments (such as UNIX)
but they provide a datastream into the host using a single base I/O
address. RBBS-PC must receive its communications at a separate base I/O
for each port.
APPENDIX I -- RBBS-PC in a DESQview Environment I-7
Here's a chart of generally accepted IRQs and base I/O addresses for the
standard PC/AT and PS/2. Although these are the common settings, they vary
(and we stress VARY) according to serial card manufacturer.
Standard AT BUS Microchannel (PS/2) BUS
------------------------------------------------------------------------
PORT BASE I/O IRQ PORT BASE I/O IRQ
------------------------------------------------------------------------
COM1 3F8h IRQ4 COM1 3F8h IRQ4
COM2 2F8h IRQ3 COM2 2F8h IRQ3
COM3 3E8h IRQ4 COM3 3220h IRQ3
COM4 2E8h IRQ3 COM4 3228h IRQ3
COM5 3F8h IRQ4 COM5 4220h IRQ3
COM6 2F8h IRQ3 COM6 4228h IRQ3
COM7 3E8h IRQ4 COM7 5220h IRQ3
COM8 2E8h IRQ3 COM8 5228h IRQ3
------------------------------------------------------------------------
If you intend to duplicate the 4-node configuration as in the preceding
example, you will need to find a serial card that will let you choose any
IRQ from IRQ3 to IRQ7 for each port (1 through 4).
In closing, there are also some important issues to consider when choosing
to go beyond two ports on a single computer. These include:
1) EXTERNAL PROTOCOL SUPPORT. The external protocol drivers you choose
must let you either define the IRQ for the additional ports, or they
just rely on the fossil driver for their communications. In other
words, they must have support for fossil drivers. Some protocols scan
a port for I/O without using an IRQ. These will probably work if you
use standard base I/O addresses for your additional ports.
2) CPU SPEED LIMITATIONS. Here's a chart indicating recommendations for
each computer type, amount of EEMS memory and number of nodes.
--- PERFORMANCE ---
HOST 1-Node 2-Nodes 3-Nodes 4-Nodes 5-Nodes 6-Nodes 7-Nodes
8-Nodes
COMPUTER 640k 1.4Mb 2.0Mb 2.6Mb 3.2Mb 3.8Mb 4.4Mb 5.0Mb
------------------------------------------------------------------------
PC 4.77-MHz A2 C3 F5 F5 F5 F5 F5 F5
PC 8-12-MHz A1 B2 D5 F5 F5 F5 F5 F5
AT 8-12-MHz A1 B2 C4 D5 F5 F5 F5 F5
AT 16-20-MHz A1 A1 B3 C3 D5 D5 F5 F5
80386/SX A1 A1 A2 B2 C4 C4 D5 D5
80386/16-MHz A1 A1 A2 A2 B3 B3 C4 C4
80386/25-MHz A1 A1 A2 A2 B3 B3 C3 C3
80386/33-MHz A1 A1 A1 A2 B3 B3 B3 B3
--------------------------------------------------------------------------
A=EXCELLENT at 2400-bps 1=EXCELLENT at 9600-bps
B=GOOD at 2400-bps 2=GOOD at 9600-bps
C=MARGINAL at 2400-bps 3=MARGINAL at 9600-bps
D=POOR at 2400-bps 4=POOR at 9600-bps
F=Not Recommended 5=Not Recommended at 9600-bps
--------------------------------------------------------------------------
Your results may vary due to specific hardware differences.
If you plan to support BPS rates of 9600 or above on one or more nodes, we
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL I-8
recommend the use of NS16550AFN UART chips. These chips are necessary for
acceptable Zmodem (DSZ) performance under DESQview.
12. RBBS-PC Technical Support For DESQview
------------------------------------------
If you would like additional information about DESQview and RBBS-PC, you
may contact the following RBBS-PC system:
Indiana On-Line (tm)
John L. Taylor, SysOp
(812) 332-RBBS (3/12/24/96/14.4KBPS)
APPENDIX J -- Using RBBS-PC with DoubleDOS J-1
APPENDIX J -- Using RBBS-PC with DoubleDOS
------------------------------------------
Two nodes of RBBS-PC can be operated on one 640K PC/XT/AT under DoubleDOS.
First, make sure DoubleDOS and RBBS-PC, individually, operate correctly on
your computer. Then, the DDCONFIG.SYS file can be changed to facilitate
operation of RBBS. SoftLogic Solutions, the DoubleDOS supplier, operates a
customer service BBS at 603-644-5556 and can often help with special
problems. (An example: DoubleDos version 4.0 must be modified with their
special patch in order to operate on machines using EEMS memory controlled
by AST's REMM.SYS driver.)
DoubleDOS even has a special interrupt that RBBS-PC calls to "give back"
unused time to the foreground job when it really doesn't need the time, so
that during periods of low communications activity, the foreground job runs
at essentially 100% of the machine's speed. GIVEBACK is incorporated into
releases 16.1A (and greater) of RBBS-PC.
The DOS (3.1 or greater) utility SHARE should be run before starting
DoubleDOS to provide for file locking.
RBBS-PC, due to the code generated by the BASIC compiler, requires a
considerable amount of memory. If insufficient memory is available, RBBS-
PC may fail to load, may report a string corrupt error, may hang, or, worst
of all, may appear to start and operate normally only to fail later. A
(partial) test of whether enough memory is available is to note the DS free
space in the SysOp initial menu when operating under DoubleDOS compared to
naked DOS; any reduction in this reported free space may indicate memory
shortage. The best approach, unfortunately, is to start with more memory
than necessary, get your system going reliably, and then do a crude cut-
and-try process of reducing memory until problems first appear; then back
off up to an again-reliable memory setting.
Terminate-and-stay-resident programs (e.g. ramdisks, print spoolers, Side
Kick) will reduce the memory available to RBBS-PC. Buffers specified in
the CONFIG.SYS file also reduce available memory. Some versions of DOS are
smaller than others; every little bit of memory helps. Large programs may
not run in the second DoubleDos memory section after starting RBBS-PC in
the first.
Because of these memory considerations, SHELLing to DOORS and external file
transfer protocols will not be possible. If these features of RBBS-PC are
used, they will need to be invoked by EXITing to them.
The BASIC compiler version used determines the amount of memory required.
Two nodes of RBBS(version 16.1A), have been demonstrated to operate
successfully under DoubleDOS when compiled with Quick Basic 1.02 and RBBS-
PC's memory requirements reduced (see Appendix U). When compiled with
Quick Basic 2.x, 3.x or 4.x, two nodes will not fit under DoubleDOS. To
save memory, expert SysOps who are adept at compiling/linking their own
custom versions of RBBS-PC, can selectively (and at their own risk) delete
from the source code sections that they do not require. Such personal
versions should not be circulated to others. If this is done, the more
recent compilers may produce code compact enough for 2 nodes.
DoubleDOS has several parameters that can improve RBBS-PC operation.
Sample:
menu = short ;the long menu requires more memory
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL J-2
display = text ;to not reserve graphics buffer
print driver = direct ;use direct drive, no buffer reserved
bottom size = half ;split memory for two RBBS-PC nodes
priority = equal ;both nodes run at same speed
The next items may be desirable to provide protection, in case any program
in the other memory section should try to use a COM port assigned to RBBS-
PC.
com1 = top ;obviously these two port
assignments
com2 = bottom ;could be reversed
Possible circumstances that might warrant this protection:
1.SysOp makes a COM port assignment error in the .DEF file for the other
node.
2.one node is temporarily shut down by the SysOp to run another program.
Some programs (e.g. some versions of BASIC) initialize both COM ports
(clobbering RBBS-PC) when started.
Warning: this protection is known to be unusable on some machines (e.g.,
works fine on IBM-PC 8088, does not work on AST Premium 286 or TATUNG 4000
AT).
It is convenient (and safer, to prevent keystroke errors) to automate your
startup. In your AUTOEXEC.BAT file you should initiate DOUBLEDOS as the
last item. It will then start, using the DDCONFIG.SYS file for detailed
RBBS-PC instructions. Sample DDCONFIG.SYS contents (this will vary
according to your exact setup):
top program = prompt TOP $p$g
top program = go
bottom program = prompt BOT $p$g
bottom program = go
Note that the change in prompt allows a single batch file, GO.BAT, which
has the single statement of GO%PROMPT%, to execute the correct node of
RBBS-PC in either node. Nothing is more embarrassing than to start a node
that is already operating. All that need be typed is GO<RETURN> and either
GOTOP or GOBOT will be executed. (Actually the GO batch file execution
looks like "TOP C:\DDOS>GOTOP $p$g". The $p$g is ignored.) GOTOP.BAT
might then look like this:
C:
CD\RBBS
RBBS1
RBBS1.BAT would then be the first node RBBS.BAT as discussed in this
document. Similarly, GOBOT would start RBBS2.BAT for the second node.
Stan Staten, RBBS-PC number (301) 670-9621
Kurt Riegel, RBBS-PC number (202) 524-1837)
APPENDIX K -- RBBS-PC in a MultiLink Environment K-1
APPENDIX K -- RBBS-PC in a MultiLink Environment
------------------------------------------------
RBBS-PC only runs under Multilink versions 4.0, 3.02 and earlier.
CONFIG's allows the SysOp to tell RBBS-PC that it will be running in a
MultiLink environment. This is ESSENTIAL when running RBBS-PC under
MultiLink. CONFIG allows the SysOp to specify what MultiLink terminal type
code to pass to MultiLink whenever RBBS-PC exits to DOS via a "Door". The
MultiLink documentation specifies the various terminal type codes. When a
SysOp indicates that "doors" are available (via parameter 101 of CONFIG)
and RBBS-PC is to be run under MultiLink, the SysOp is asked to select the
MultiLink terminal type that RBBS-PC is to inform MultiLink to expect when
MultiLink is given control of the "Door."
RBBS-PC has been tested running two copies of RBBS-PC under DOS 3.2 and
MultiLink Advanced (versions 3.02 and 4.0) on an IBM PC which had a mother-
board containing 256K and an AST Comboplus board with 384K (a total of
640K). However, to do this RBBS-PC must be re-compiled (see Appendix U).
The "autoexec" file was named AUTOEXEC.BAT and contained the following
parameters
MLINK /9,266/9,266
NOTE! ==>RBBS-PC must be recompiled with C:512 in order to run in a 268K
partition under MultiLink. As released, RBBS-PC is compiled with the
parameter C:4096 which requires a MultiLink partition of 270K. Of course,
to SHELL to the external protocols, the partitions must be about 440K.
It is important to avoid doing several things when running RBBS-PC under
MultiLink. First, NEVER RUN MLSLICE! This is because MLSLICE hangs off
the PC's timer chain and the code generated by the BASIC compilers violates
all sorts of DOS conventions whenever it is utilizing the PC's speaker
(i.e. as when RBBS-PC pages the SysOp). In so doing, the code generated by
the BASIC compilers is incompatible with programs that do follow DOS
conventions.
Second, NEVER use the DOS "PRINT" command! This is because there is a bug
in the code generated by the BASIC compiler that causes the system to hang
if a compiled BASIC program is running and DOS is printing something. This
bug has been corrected in the BASIC compiler that was used to generate
RBBS-PC.EXE that is distributed. However the version of RBBS-PC that you
get (if other than from CPCUG) may not have this bug corrected. This is a
bug that occurs independent of running MultiLink.
Third, check your Intel 8088 chip's copyright date by opening up the cover
and locating the 8088 chip. If the copyright date printed on the chip is
1978 (i.e. pre 1981), REPLACE THE INTEL 8088 CHIP!!!!! The 1978 Intel 8088
chip had several design flaws that will cause your system to lock up
occasionally. One of these design flaws allowed interrupts to occur while
stack switching (something that will happen running multiple partitions
doing disk I/O under any multi-tasking DOS add-on such as MultiLink or even
IBM's TopView). Don't blame MultiLink for the flawed Intel 8088 chip that
IBM put in your PC! It costs about $70 ($35 for the chip and $35 for
labor) and takes about 15 minutes to have the 1978 Intel 8088 chip
replaced. In fact, if you are going to replace your 1978 Intel 8088 chip,
you might consider the newer (and 5% to 10% faster) NEC V20 chip.
Fourth, DON'T USE "BUFFERS=" in the CONFIG.SYS for DOS! This may be an
"old wives tale," but I am convinced (but can't prove) that there are
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL K-2
incompatibilities between the code the BASIC compiler generates, DOS's use
of "BUFFERS=", and MultiLink.
fifth, RBBS-PC will only run in Background 1 or Background 2.
Finally, DON'T RUN PROGRAMS THAT USE THE BASIC "RUN-TIME" LIBRARY, and
always invoke the BASIC interpreter with the command BASIC /C:0! Both the
BASIC interpreter's handling of communications ports and BASRUN.EXE seem to
violate enough DOS conventions to "lock up" MultiLink.
When RBBS-PC is told that it is running in a MultiLink environment via
CONFIG parameter 162, RBBS-PC will automatically do the following:
1) When re-cycling, it will automatically enqueue on the correct
MultiLink resource ID for the communications port defined in CONFIG
for that copy of RBBS-PC to use.
2) When re-cycling, it will automatically tell MultiLink that this is a
type "9" partition (i.e. MultiLink is NOT to handle the communications
port).
3) When exiting to DOS via a "door", RBBS-PC will automatically
tell MultiLink to start handling the communications for this
partition (COM1 or COM2) and what type of terminal was defined
in CONFIG that would be on the communications port (MultiLink
terminal types 1 through 12).
Manually, it is possible to bring up and run one copy of RBBS-PC under
MultiLink. The only way that I have been able to bring up two copies of
RBBS-PC successfully (one copy running in each of two partitions) was to
bring them up via AUTOEXE1.BAT and AUTOEXE2.BAT files. It appears that
during the MultiLink initialization sequence when the partitions are being
established and the "AUTOEXEx.BAT" files are being invoked that MultiLink
doesn't get "confused" and lock up with a second copy of RBBS-PC present.
If using Multi-Link to run multiple nodes in the same machine under
DOS 3.x or above, it is recommended that the SysOp execute SHARE.COM prior
to starting multiple RBBS-PC nodes under Multi-Link and specify FILES=20 in
the CONFIG.SYS file.
APPENDIX L -- RBBS-PC in a CORVUS Network L-1
APPENDIX L -- RBBS-PC in a CORVUS Network
-----------------------------------------
RBBS-PC uses the standard Corvus SEMAPHORES when sharing files among
multiple copies of RBBS-PC within a Corvus Network. This is accomplished
via the MS-DOS utility driver, DRIVEC2, that Corvus supplies with its
network.
On a multi-server Corvus network (i.e. where there are multiple shared hard
disk drives) all PC's that are running RBBS-PC within the Corvus network
MUST have their "home volume" on the same server. Corvus maintains each
PC's semaphores on that PC's "home volume". In order to "share" files
among various PC's in a Corvus network, all the PC's that are "sharing"
must also be looking at the same set of semaphores. In a single-server
Corvus network this is not a consideration because there is only one "home
volume."
RBBS-PC has been only tested with the Corvus CONSTELLATION II interface
cards and software that Corvus provides for the IBM PC. RBBS-PC should
work with both Corvus' older "flat cable" network as well as their newer
OMNINET twisted wire pair cable network when running CONSTELLATION II
software. It is entirely possible that RBBS-PC would work with some
combination of both Corvus network types as long as they were running
CONSTELLATION II software.
It should be self-evident that every PC within a Corvus network running
RBBS-PC must have a Corvus interface card. If multiple copies of RBBS-PC
are running in a Corvus network that is using older Corvus software (i.e.
NOT running the CONSTELLATION II software), the interface cards must, at
least, all have the CONSTELLATION II ROM.
RBBS-PC is tested only to run on IBM PC's within a Corvus network. Clearly
an IBM "clone" that can run IBM's DOS, RBBS-PC.EXE, and is supported by
Corvus' network should also work. However, such configurations (and their
many variations) are not part of the environment within which RBBS-PC is
tested and supported.
APPENDIX M -- RBBS-PC in ORCHID or AST PCnet NETWORK M-1
APPENDIX M -- RBBS-PC in ORCHID or AST PCnet NETWORK
----------------------------------------------------
RBBS-PC can be implemented on an Orchid PCnet or AST PCnet Network
environment. It is assumed that the necessary network hardware is
installed correctly. The following discussion describes a network
currently in operation and receiving more than 1000 calls per week on two
telephone lines for the Computer Connection of Virginia Beach. The
hardware and software was:
1. 80286 based SERVER with 512K running at up to 9 MHz with:
Parallel-Serial Board on the AT with a serial port addressed as COM1
AST Rampage memory board configured with 2 megs of expanded memory
Monochrome Adapter with parallel printer port
PC Net adapter addressed as 0080 with default jumpers
Hard disk that can be divided into multiple volumes
Single High Density [1.2 meg] floppy disk
External modem and cable connected to COM1
2. 8088 based WORKSTATION with 640K running at up to 8 MHz with:
multifunction board with COM1, a clock, and parallel port
PC Net adapter addressed as 0011 with default jumpers
Color Graphics Adapter
Two 360K floppy drives
External modem and cable connected to COM1
3. Software -
Operating System = DOS 3.1 network-wide
Network Software = Orchid PC Net 3.0a
Disk Caching Software = Orchid CACHE.EXE version 2.2
RAM Disk = AST FASTDISK
Installation procedures ---
1. Preliminaries
1. Backup hard disk, system and network disks.
2. If your hardware is different, be sure to resolve INTerrupt conflicts
with the PC NET adapters. Disable second serial or parallel ports in all
PC's.
2. Using the WORKSTATION, boot with DOS 3.1 then
1. Create the SERVER and WORKSTATION boot disks with SPCGEN and UPCGEN
commands, respectively.
2. Copy device drivers for the hard disk, for the RAM disk, and for
Expanded and Extended memory (REMM.SYS and REX.SYS) to the SERVER boot disk
as well as CACHE.EXE. Place the following CONFIG.SYS file for the SERVER:
device=spc.com <-- Network SERVER driver
device=REMM.SYS <-- Expanded memory driver
device=rex.sys 1024 <-- 1MB Emulated extended memory
device=fastdisk.sys 1024 512 128 /e <-- RAM disk in extended memory
3. Place the following commands in the AUTOEXEC.BAT file:
disk13 <-- Network for floppy disk use
cache [drives] d=128 x=896 /r <-- 128K cache of DOS memory & 896K of
EMS memory for SERVER drives to reduce the number of disk accesses
spcbio 138023 <-- Tell network of interrupts used
4. Using the SERVER, boot with the newly created SERVER boot disk
1. Run the network program SPCINST.
2. After naming all the available drives on the server, assign all the
hard drive volumes to the WORKSTATION # 11 and them all READ/WRITE capable.
"Remote Execution" need not be enabled.
3. The SERVER will then reboot and the network will have the final
configuration as outlined above.
5. Boot the WORKSTATION with the newly created WORKSTATION boot disk and:
1. Add FILES = 16 to the CONFIG.SYS file for the WORKSTATION.
2. Use the network program UPCINST to communicate with SERVER # 80.
3. "Map" in all the drives that were assigned by the SERVER.
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL M-2
4. The WORKSTATION will reboot so the changes can take effect.
5. After the WORKSTATION reboots, do a DIR C: to see if the directory on
the SERVER hard disk can be read. If not, recheck cables, plug-in cards
for INTerrupt conflicts, and network adapter cards to verify all jumper
settings. If necessary, run the SELFTEST and NETTEST diagnostics for the
network adapter cards. Also, demonstrate the ability to copy files across
the network to and from the server then verify the transfer using the COMP
command.
6. Assuming that you are able to do a DIR across the network and copy files
to and from the SERVER, you are then ready to run CONFIG.EXE of RBBS-PC.
Run CONFIG and confirm use of RBBS-PC in a multinode environment. Assign
the number 1 Node to your SERVER.
1. Assign all welcome, bulletin, help and menu files to the SERVER's RAM
drive so the workstation may access them in the fastest way.
2. Store FILESEC, PASSWRDS, MESSAGES, USERS and other sensitive files in a
non-downloadable but sharable drive volume on the SERVER so the workstation
may have read/write access to them.
3. Select a location for the SERVER's CALLERS file and the WORKSTATION's.
4. Reflect the node numbers in the BATch file names, e.g. RCTTY1.BAT and
RCTTY2.BAT, RBBS1.BAT and RBBS2.BAT.
5. Choose PCNET as the environment that you are running RBBS-PC under.
Other Considerations--
VDISK or Extended memory, which is not-emulated memory, should not be used
on the SERVER but can be used on the Workstation. The network
configuration most likely to remain operating with very few problems is DOS
3.1, Orchid 3.0a PC NET software and CACHE.EXE version 2.2 and an
Expanded/Extended memory combination using the new Lotus/Intel/Microsoft
EMS memory boards.
Two nodes can be efficiently set up using the SERVER in non-dedicated mode
but the danger is that if the SERVER locks up, the whole system locks up.
The sample PC Net system is set up in this fashion but it is an economical
approach to a two node system which has been functioning quite well with
minimal problems. Do not run software on the SERVER that is known to cause
problems especially memory resident utilities. There is a potential for
files being CROSS-LINKED in any read/write sharable environment. Frequent
backups are to be very strongly recommended.
Because of wide variety of hardware combinations and possible network
permutations, the above is intended ONLY as general guidelines to be
followed when installing RBBS-PC on your Orchid network.
Rob Cecchino
SysOp, Computer Connection
(804) 481-1824 at 1200/2400 for assistance.
APPENDIX N -- RBBS-PC in an Alloy PC-SLAVE/16 Environment N-1
APPENDIX N -- RBBS-PC in an Alloy PC-SLAVE/16 Environment
---------------------------------------------------------
The PC-Slave is an IBM compatible computer on an expansion card
manufactured by Alloy Computer Products, Inc. of Framingham, MA 01701.
Their telephone number is (617) 875-6100. Adding PC-Slaves converts the PC
from a single CPU to a multiple CPU, all under the control of the main or
host PC. Each slave can run RBBS-PC (or other programs).
A. THE ADVANTAGES: Compared to other means for running multiple RBBS-PC's,
the advantages of slaves are:
1. SPEED -- Each copy of RBBS-PC has a dedicated computer and therefore
runs very fast compared to multi-tasking products like Multi-Link,
DesqView, or DoubleDOS.
2. SHARED FILES -- Each bulletin board can share files, including the users
and messages. The PC Slave system can act like Orchid's PC-Net network, or
a NetBIOS LAN for record locking.
3.EXPANDABILITY -- You can have up to 31 slaves. Adding an extra Slave is
simple, and does not degrade system performance. The power supply and
cooling capacity of a PC-2 or XT limit you to adding only 2 slaves. An AT
can have up to four. You can buy PC compatibles that have more expansion
slots. You can also get an expansion chassis designed for up to 12 Slaves.
4. COSTS -- It is far cheaper to expand using PC-Slave/16's than a network.
The PC-Slave lists for $900 and can be purchased for significantly less.
Other networks require not only a separate PC but also a "network" card of
some sort which puts the costs of each port well above $2,000.
5. DEDICATED PC IS NOT REQUIRED -- Your PC can remain free for you to use
while slaves run the bulletin boards (or run another copy of the bulletin
board). You do not degrade performance on the slaves, except for
contention for the hard disk and that can be mitigated by using disk
caching.
6. EASY SNOOP. Using Alloy utilities GIMME and VIEW, you can view the
session on any slave and attach your keyboard to it. You can also install
a dumb monitor to any slave.
B. THE DISADVANTAGES: The disadvantages of a slave system are:
1. COMPATIBILITY --Not all hard disks are compatible with the slaves. Hard
disks known to be compatible include the Seagates, Priam 60 meg, Bernoulli,
and Maxtor hard disks, as well as the Alloy line of hard disks. Hard disks
definitely not compatible include all models of US Design.
C. OVERVIEW OF SETTING UP A PC-SLAVE/16 RBBS-PC: Five easy steps on how to
install RBBS-PC in a PC-Slave/16 environment (Note that the PC Slave system
requires a special configuration for RBBS-PC):
STEP 1 -- If you want to allow simultaneous callers, you will have to
purchase multiple telephone lines. They can be made to roll so that only
one number is called, and if busy, the call will roll over to the other
lines.
STEP 2 -- Install the slaves. Remember to set switches on the slave boards
that number them consecutively. See the PC-Slave documentation for
details.
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL N-2
STEP 3 -- Install the software. The Alloy PC-Slave has to have special
Alloy software called NTNX to coordinate the slaves and process requests
for shared resources. See the NTNX documentation for details.
STEP 4 -- Install a modem with no pin 22. Pin 22 used to be required with
RBBS-PC in order to answer the phone. On the slaves, pin 22 CANNOT be
connected, or else the slave will continuously reboot. However, newer
slaves support pin 22.
STEP 5 -- Configure RBBS-PC using CONFIG.EXE with the following parameters:
(a) use COM2 (parameter 221)
(b) Via parameter 29 tell RBBS-PC it is running on an IBM compatible
rather than a PC, XT, or AT. (Lie and tell RBBS-PC you have a Compaq
Plus.)
(c) Use CONFIG parameter 161 to set the maximum number of bulletin
boards to as many boards as you intend to install (rather than the number
you are currently running. This makes expansion easier.).
(d) PC-Net is the multi-user environment you will be running under
and should indicate so via CONFIG parameter 162.
(e) Set up the RBBS-PC files.
Read Appendix G for general considerations on running a multi-node RBBS-PC
system. Since all PC-Slaves have access to all hard drives, configuration
of files is quite simple.
Please note that the NTNX software is very vulnerable to any RAM resident
software. You should install the Slaves with no additional software
present and carefully test any resident software you want to run with it.
D. A DETAILED DESCRIPTION OF SETTING UP A PC-SLAVE 16 RBBS-PC:
Hardware Limitations:
1. Two PC/Slave 16 cards per XT box or four in an AT maximum otherwise
you'll be buying power supplies frequently. An expansion chassis for four
cards (Alloy Plus4) or expansion chassis for up to twelve cards will be
needed for bigger systems. Expansions boxes can be daisy-chained to up to
thirty one Nodes or workstations, if needed.
2. PC/Slave 16 cards do not support PIN 22 for Ring Detect. If PIN 22 is
connected, your slave will re-boot every time the phone rings!
3. No clock on the PC/Slave 16 card. The Slave gets the Time and date from
the main system clock. Each time you update the host clock, all the slaves
will update as well.
4. A terminal such as a Kimtron KT-7/PC or Alloy PCST is needed if you want
to work on a slave the same as you would on the host computer (but not if
you just want to view activity on slaves occasionally). Other terminals
will work but may not support all of the IBM extended graphics codes. For
a multi-node RBBS-PC, one terminal can be used with an A-B-C-D switching
box to 'dial in' to the node you wish to work with.
5. The Slaves' CPU [NEC V20 @ 8 MHz] shuts down when writing to the hard
disk. This creates problems with timeout errors on uploads. Upload
problems can be eliminated by using the write buffer option in NTNX 1.64 or
higher (/B). The problem can also be alleviated by using a fast hard drive
supported by Alloy. Also, the hard drive must be formatted with the most
efficient interleave setting and driver. Hard drives that work without
APPENDIX N -- RBBS-PC in an Alloy PC-SLAVE/16 Environment N-3
significant upload timeout errors have been formatted with either Golden
Bow's Vfeature Deluxe or Priam's formatting software; this problem is
especially noticeable on AT systems and not too much of a problem on small
XT systems. Seagate, Bernoulli Box, Maxtor, and Priam Inner Space drives
seem to work fine with the Alloy PC/Slave-16 cards.
Software Limitations:
1. ATNX runs Orchid PC Net applications but NTNX is more versatile and will
run applications for Novell's Advanced Netware, MS-Net, AND Orchid PC Net
with proper file locking. NTNX has had less problems with file corruption
and cross-linking than ATNX, according to SysOps using Alloy Slaves.
2. The slaves get the date/time from the host computer. Constant
processing can cause the host clock to drift. A utility to periodically
update your host computer clock is recommended. Also, WXMODEM does not
work in upload mode on Slaves due to a timing problem in the initial
handshake. Alloy's solution to this problem is a file called UPTIME.COM,
which is run on the HOST, but I have had very poor results with it. The
problem seems to be most identifiable on AT class machines.
For the optimum system flexibility you may want to buy Alloy PC/Slave-16N
cards which have the special PAL chip for NTNX/Novell compatibility and
NTNX software. RBBS-PC, however, will run fine without the PAL chip even
under NTNX.
Some nice additional utilities for the Slaves, including special
diagnostics, are found in the separate PC-Plus Advanced User's Kit and are
worth having. A single Kimtron KT-7/PC terminal or other smart terminal
may be obtained right away but is not necessary for the bulletin-board-only
system as one can always sign on from remote for answering mail; pay
special attention to the terminal-to-Slave cable as it is non-standard and
you'll probably wind up making it yourself for less than $5 in parts -- one
end is a male 9-pin D-shell and the other is 25-pin RS-232 male connector.
For a two to four node system, obtain a switch box to hook the terminal as
COMMON and Slave consoles. The computer to house the Slaves, called the
HOST, should be the quickest CPU speed that you can obtain. All PC
Slaves/16 should be purchased with 1 megabyte of onboard RAM.
Installation:
1. Format your hard drive with the DOS supported by the version of NTNX you
purchase (currently DOS 3.3).
2. Divide the hard drive into multiple volumes of standard DOS size (less
than 32 megabytes).
3. Install NTNX and the Slaves according to the Alloy manuals. Choose the
default settings for everything. Use 512K on the 1 megabyte PC/Slave for
caching and the other 512 to run RBBS. Depending on how the board is
configured, you may need to set switches so that 512 is used to run
applications. Use 4K for the Host PC caching. Allocate 25 files per each
Slave + 64 for the maximum number of open files.
4. Set up the CONFIG.SYS and AUTOEXEC.BAT files for the HOST as follows
especially if you do not plan to use the HOST as a Node for RBBS-PC:
CONFIG.SYS
device=NX.SYS - NTNX driver (must be first!!)
device=hard_drv.sys - Your hard Disk driver
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL N-4
FCBS = 32,32 - File Control Blocks increased
buffers = 20 - DOS buffers
files = 32 - Number of OPEN files on HOST
device = ANSI.sys - Extended graphics driver
AUTOEXEC.BAT
NTNX - NTNX driver
fm 3 - Level of File protection
prompt $p$g - customized dos prompt
path = ........ - set path to the NTNX files
5. Set up the CONFIG.SYS and AUTOEXEC.BAT files for the Slaves as follows:
CONFIG.U0x under DOS 3.3
FCBS = 32,32
buffers = 10
files = 30
device = ansi.sys
shell = C:\COMMAND.SLV C:\ /P /E:800
Of special note, the SHELL statement has been used to expand the
environment space on the Slaves. This corrects a problem seen with random
RBBS-PC lockups or getting Out of Memory errors; external protocols and
DOOR programs, given time, stop running due to memory problems if one
doesn't use this SHELL statement. Under DOS 3.1, set /E:50 [= 50
paragraphs] and under DOS 3.2 or 3.3, set /E:800 [= 800 bytes].
AUTOEXEC.U0x
fm 3
prompt $p$g
path = .......Set the path to the NTNX files and to the 'home'
directory for this node on the SHARED drives
SET NODE=x Tell this slave what node to run.
cd\RBBS0%NODE% Change to the RBBS-PC directory for this node
RBBS.BAT Invoke RBBS-PC for this node
The statement "SET NODE=x" allows you to write batch files that know what
node you are dealing with. All slaves can access the same RBBS.BAT file,
as long as you invoke RBBS-PC from within that file as:
RBBS-PC %NODE% RBBS%NODE%PC.DEF
Other node-specific commands should be done this way.
6. CONFIG parameters for the slaves, must be the following parameters:
Parameter 29 (Type of computer): Compaq Plus.
Parameter 224 (Number of rings to wait before answering): 0.
Parameter 162 (Environment): Orchid PC Net.
Parameter 221 (Communications port): 2.
Maximum number of users: at least as many slaves as you have, plus
one if you plan to run a node on the host. You can specify more (up to 36)
if you want to plan for expansion.
7. Set up RBBS-PC as follows:
Create subdirectories \RBBS01, \RBBS02, \RBBS0x... on a shared drive.
Create other subdirectories according to RBBS-PC documentation.
On a cached drive, place all static RBBS-PC files such as MENUs,
HELPs, PASSWRDS, TRASHCAN, external file transfer protocols. RBBS-PC.EXE
and CONFIG.EXE go here as well.
On the second SHARED drive, make a subdirectory \COMMON for MESSAGES,
USERS, CONFENCE, and conference message/user files.
APPENDIX N -- RBBS-PC in an Alloy PC-SLAVE/16 Environment N-5
If you plan to use DOORS, especially Bob Westcott's DOORWARE, create
a subdirectory called \DOORS on the SHARED drive.
Run CONFIG and create RBBSxPC.DEF files for all your nodes. Remember
that you will run multi-user under PC Net. The modem serial port on the
Slaves is COM2 and not COM1. Double-check file locations! Put your static
text files in the same subdir as MESSAGES and USERS and make it the default
subdirectory
Copy RBBS1PC.DEF to RBBSxPC.DEF for each node that you hope to have
then re-edit each .DEF file to customize Node numbers such as RCTTY1.BAT,
etc.
Copy the RBBSxPC.DEF file to the matching subdirectory. If you don't wish
to edit the .DEF files, place RBBSxPC.DEF on one shared drive and place the
dynamic RBBS-PC files on the other shared drive; be sure that you have at
least logged into that other SHARED drive's subdirectory, using the
AUTOEXEC.U0x before starting RBBS-PC or else RBBS-PC will not find those
files.
Temporary files used for transfer or Verbose ARC listing are created
on the default subdirectory automatically. You must assign a different
CALLERS file for each node located in the default directory.
To use SysOp Function 7 (Remote Drop to DOS), RBBS-PC must find
COMMAND.COM. PC-Slave/16's, however, use COMMAND.SLV as the command
processor; copy COMMAND.SLV to COMMAND.COM, place it on a cached drive, and
tell CONFIG where to find it. Be careful using this SysOp function with
the Slaves as you will lock up the Node if you lose carrier; WATCHDOG is
incompatible with the Slaves.
Additional tips/hints:
1. Avoid using any memory resident utilities. They may interfere with
Slave operation.
2. A program on the Advanced Utilities disk called SEE.COM allows callers
on any Node to be viewed from the HOST.
3. Norton's Editor or WordPerfect Corporation's Programmers Editor from the
WordPerfect Library is used for editing operations on the system,
especially for maintaining the fixed-length directory of the file
management system. Not many other editors, except EDLIN, can be used
reliably.
4. Easy to forget but don't as it will be a source of frustration -- plan
out your file locations on paper before actually setting up the system.
5. Backup your system frequently!
If you have any questions or problems, feel free to leave a message on Ken
Goosens system (703) 978-6360.
APPENDIX O -- RBBS-PC and 10 NET Network O-1
APPENDIX O -- RBBS-PC and 10 NET Network
----------------------------------------
Starting with RBBS-PC 15.1A support for Fox Research's' 10 Net Network is
being provided.
Since this is the first release with this support we have very little that
we can offer in tuning support for 10 NET.
We selected to use the Semaphore locking mechanism that we have used in the
other networks and therefore you must specify the following parameters on
the Superstation in your 10 NET network.
LOGINS=x 1 for every node on the system
OPENFILE=xxx 10 for every node running RBBS-PC
SHAREFIL=16 (This is the default you can add more if you want)
LOCKS=x 3
SEMA=xxx 3 for every node running RBBS-PC
You will also need to run NETSU and specify option 6 (DOS file sharing).
Please note that these values should be in addition to any parameters you
may have already specified for other User stations and other uses of your
10 NET network. And you can always make the values larger in attempting to
improve performance.
APPENDIX P -- Running RBBS-PC on a NETBIOS network P-1
APPENDIX P -- Running RBBS-PC on a NETBIOS network
--------------------------------------------------
CONFIG parameter 162 allows the SysOp to select an environment for running
multiple copies of RBBS-PC. One of the environments is "DOS SHARE," which
allows a large number of LANs to support RBBS-PC. Any LAN that is
"NetBIOS" compatible should allow RBBS-PC to run multiple nodes, since the
DOS SHARE utility is usually supported with all NetBIOS LANS. Operating
RBBS-PC on a network which supports the NETBIOS interface is therefore very
simple. Outlined step-by-step, the procedure is as follows:
1) Install and load your network software.
2) Configure RBBS-PC for the network environment.
3) Prepare files which are to be shared, but not written to.
Let's discuss these items in detail.
INSTALL AND LOAD YOUR NETWORK SOFTWARE
Obviously, for each different network, this procedure will change.
This manual doesn't attempt to replace or augment the documentation
which accompanied your network software. It only covers how to set up
RBBS-PC to work with a NETBIOS LAN. The assumption is made that you
can, and have, correctly installed your network.
However, so that you understand what we mean by "install and load", we
will present a generic description here. (It should be noted that
there are certain similarities between all NETBIOS LAN products.)
First, the "core" of the network software must be loaded after you
boot the machine (e.g. the NET START command). Next, any of your
computer's resources which others require access to must be "shared"
(e.g. the NET SHARE command). And finally, any resources which your
computer requires access to must be "used" (e.g. the NET USE command).
Please note that NET START, NET SHARE, and NET USE are all examples of
the commands used by the IBM PC LAN Program. Your actual commands
might be different.
CONFIGURE RBBS-PC FOR THE NETWORK ENVIRONMENT
Begin by running the RBBS-PC CONFIG utility. Set parameter 162 to
"6", which tells it that RBBS-PC is running on a NETBIOS LAN. (Please
check parameter 161 while you are there, also, and make sure that it
is correct for the number of nodes you intend to run.)
You will notice, when you select parameter 162, the reference to the
DOS utility SHARE.EXE. This utility must be loaded in order for a
NETBIOS LAN to function properly. The startup command for most
networks will cause SHARE.EXE to be loaded (i.e. when the NET START
command is issued, the network looks in the current path for SHARE.EXE
and loads it).
If, for some odd reason, your network does not automatically load
SHARE.EXE, you will need to perform this task manually in your
AUTOEXEC.BAT file (DOS 4.x users can opt for the "INSTALL=" option in
their CONFIG.SYS files).
PREPARE FILES WHICH ARE TO BE SHARED, BUT NOT WRITTEN TO
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL P-2
Once RBBS-PC is aware of the fact that you're running on a NETBIOS
LAN, it will open all of the files it intends to update in "shared"
mode. However, when RBBS-PC opens a file for READ access only, it
does NOT use DOS SHARE. This will on occasion cause sharing
violations when more than one node tries to read the same file at the
same time. To compensate for the problem, you should set the "read
only" attribute of any file which will NOT be updated during the
course of the call. Files such as WELCOME, PRELOG, all HELP, bulletin
and news files should be "read only."
(You change a file's read only status with the DOS utility ATTRIB.
The syntax is "ATTRIB +R (filename)." Please note that ATTRIB must be
located in the current search path, and the "+R" switch can be
reversed into "-R", when you want to remove a file's read only status
in order to edit it.)
We recommend setting the read only status on any file which you are
certain will not be updated (i.e. written back to).
SUMMARY
The hardest part about setting up RBBS-PC in a network environment is the
actual setup of the program for multi-node operation. But if you follow
certain guidelines (laid out for you in Appendix G), you should be fine.
APPENDIX Q -- RBBS-PC and the IBM PCjr Q-1
APPENDIX Q -- RBBS-PC and the IBM PCjr
--------------------------------------
RBBS-PC adheres to the Hayes standards for autoanswer applications that are
described in Section 9, "Writing Programs for the Smartmodem 1200," of the
SMARTMODEM 1200 HARDWARE REFERENCE MANUAL. Under the section entitled
"Additional Program Considerations" Hayes recommends that autoanswer
applications (like RBBS-PC) "... force the modem to answer the call (ATA)
rather than allowing the modem to automatically answer...." Beginning
with 13.1A, RBBS-PC no longer REQUIRES the Ring Indicator signal from the
modem (pin 22) in order to answer the phone (except if parameter 224 of
CONFIG is non-zero).
Here are some facts about the PCjr:
1) The PCjr's external modem interface does not have a Ring Indicator
signal.
2) The PCjr requires that an external modem be opened as COM1 if no
internal modem is installed. However, if no internal modem exists the
PCjr requires that the COM2 RS-232 registers be used even though the
port has been opened as COM1. Technically this is described as using
the external RS-232 asynchronous adapter as logical channel 1 (i.e.
COM1) but manipulating it as physical channel 2 (i.e. COM2). This
occurs on a PCjr only when an internal modem is NOT present and the
external RS-232 interface is.
3) The 128K PCjr only provides 90K of usable RAM (the rest is used by
DOS, the monitor's buffers, etc.). Fortunately PCjr owners can get up
to 512K of RAM with "add-on" equipment (from IBM and others) in order
to have enough RAM for RBBS-PC to run in.
4) The standard PCjr supplied by IBM does not have a DMA and hence can't
do communications I/O simultaneously while doing disk I/O.
RBBS-PC beginning with version 13.1A will run an IBM PCjr providing that
the PCjr
1) Has at least 320K of memory.
2) Disk I/O does not occur simultaneously with communications I/O (i.e.
either you have a second disk drive with a DMA or you set BUFFERS=0).
3) One of the following three modem configurations are used:
- An internal PCjr modem with an external Hayes modem where the external
Hayes modem is used for RBBS-PC.
- No internal PCjr modem with an external Hayes modem used for RBBS-PC.
- Only an internal PCjr modem and it is used for RBBS-PC.
The following discusses each of these three modem configurations supported
by RBBS-PC with the PCjr.
Internal PCjr Modem with RBBS-PC Using External Hayes Modem
-----------------------------------------------------------
This configuration means that the PCjr has both a COM1 (the internal PCjr
modem) and a COM2 (the external Hayes modem). RBBS-PC is set up to use
COM2. No changes are required to for RBBS-PC for this type of PCjr
configuration. CONFIG parameter 224 should be set to 0. This will cause
RBBS-PC to set the external Hayes modem into "auto-answer" mode and RBBS-PC
will wait for carrier detect. This is the way that RBBS-PC overcomes the
PCjr's lack of "ring-indicator" signal for the external communications
port.
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL Q-2
No Internal PCjr Modem With RBBS-PC Using External Hayes Modem
--------------------------------------------------------------
This configuration means that the PCjr has only one RS-232 interface -- the
external Hayes modem. This must be opened as COM1 but use COM2's registers
to control the communications port (believe it or not that's the way IBM
designed the PCjr).
CONFIG parameter 221 should be used to indicate that COM1 is being used.
Unfortunately the current BASIC compilers (both IBM's Version 2 and
Microsoft's QuickBASIC) are incapable of handling a communication port as
logical device 1 (i.e. COM1) but on physical channel 2 (i.e. the interrupts
are for COM2).
Should this ever be fixed by either IBM or Microsoft, CONFIG parameter 29
should be used to indicate that no internal PCjr modem is installed. This
tells CONFIG to make sure that COM2 registers are used to manipulate the
PCjr's external communications port.
Until this is fixed by the respective vendors, the PCjr user will have to
run a utility like COMSWAP that exchanges the pointers between COM1 and
COM2 within DOS.
In either case, CONFIG parameter 224 should be set to 0. This will cause
RBBS-PC to set the external Hayes modem into "auto-answer" mode and RBBS-PC
will wait for carrier detect. This is the way that RBBS-PC overcomes the
PCjr's lack of "ring-indicator" signal for the external communications
port. Again no changes to RBBS-PC are required for this type of PCjr
configuration.
Only An Internal PCjr Modem for RBBS-PC and NO External Hayes Modem
-------------------------------------------------------------------
For this type of PCjr configuration, you can take the CONFIG default
settings for the communications port (COM1) and specify that you are
running on a PCjr (parameter 29). However, make sure that CONFIG parameter
228 specifies that the modem is to be opened at 300 baud. Of course, RBBS-
PC will be only able to answer the telephone at 300 baud and send and
receive data from users who log on with their communications parameters set
at N/8/1 (i.e. no parity, eight data bits, and one stop bit) since RBBS-PC
is limited by the PCjr's own modem's limitations.
RBBS-PC already has the modem commands for the PCjr's very strange internal
modem in the logic to answer the phone so no changes to the .DEF file are
required.
APPENDIX R -- Using RBBS-PC to access ORACLE or dBASE Remotely R-1
APPENDIX R -- Using RBBS-PC to access ORACLE or dBASE Remotely
--------------------------------------------------------------
1. The Need for Data Base Services
A feature that has been long missing from PC based host communication
systems is the ability for SysOps to install customized data bases and let
callers run true interactive data base queries against them. Because data
base management is a major programming task, the most promising way to add
data base services is to use RBBS-PC's original and innovative "DOOR"
mechanism to exit RBBS-PC and have the remote user enter an existing data
base management program.
"DOORing" to a data base management program, however, is not as easy as one
might hope. The major problems stem from the fact that data base
management programs are never designed to work in this environment. This
is because:
1) Most programs write to the hardware for speed rather than use bios
calls, causing the "screen" output to appear on the host terminal
rather than on the caller's terminal.
2) Data base programs do not monitor for carrier. If carrier drops they
simply sit forever waiting for input rather than terminating.
3) Most use "full screen" rather than "line at a time", which usually
does not work properly on a remote terminal.
4) Security. Most data base programs have no way to limit what a user
can do. For example, they do not have a read-only mode, or the
ability to restrict a user to specific files or fields. Many let the
user issue dos commands inside them, which gives to call too much
power.
5) Difficulty in learning to use. A caller can hardly be expected to
know how to use a data base. Hence it must be possible to simplify
and control the user interface inside the data base package.
Progress has been made with two of the most popular PC data bases -- ORACLE
and dBASE.
Using dBASE "DOORS" with RBBS-PC
--------------------------------
db/LIB is a relatively new piece of software by AJS Publishing of North
Hollywood, CA that makes remote dBASE access possible. db/LIB is a set of
two assembled libraries which can be used to create/modify dBASE data
structures, create/update dBASE indices, and naturally manipulate the dBASE
records. These libraries also have many replacements for dBASE
functions/commands not easily replicated (i.e. IIF, RECNO(), DATE(),
RTRIM(), DELETED(), etc.) outside of the dBASE environment. db/LIB is also
available in a multi-user version.
db/LIB was designed to work with Microsoft Quick BASIC 4.0 and BASIC
Compiler 6.0 (there is a QB 2/3 version available directly from AJS
Publishing after you purchase db/LIB).
dBASE Remote Access Advantages/Disadvantages
Combine db/LIB with any well written door skeleton (such as the very fine
skeleton) and you can have a true shareable remote database system. The
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL R-2
following section highlights some advantages and addresses the problems
concerning remote dBASE database access.
Advantages of using db/LIB and dBASE data bases:
1) Purchase of dBASE is not required. db/LIB can create modify and
maintain any dBASE structure. A program with db/LIB and downloaded by
a third party can give these same freedoms to a third party. Sample
programs with db/LIB demonstrate that most of dBASE's functions can be
replicated or substituted using db/LIB.
2) If dBASE (or any good clone) is owned, then the two work very well in
tandem. The programmers at Ashton-Tate didn't gain their reputation
for writing junkware. By owning dBASE, the user can download any
database structure and perform any data manipulation easily in a
familiar environment.
3) Full screen (ANSI) writes, security, carrier monitoring, error
trapping, are all handled by the door skeleton. Let database modules
run the database, and let the door modules run the door.
Disadvantages of using db/LIB and dBASE data bases:
1) Remote dBASE database access is not the same as accessing dBASE III
remotely. Creation of these DOORS requires knowledge of Quick BASIC,
some knowledge of data communications, and some knowledge of dBASE.
All end user requirements have to be anticipated, all cases covered,
and created in advance. Once the application is created, then user
need no little or nothing about any of the above.
2) Not all users can use ANSI commands for full screen editing. This
means that doors need to have a scrolling (terminal) type display
capability as a substitute for the normal full screen writes. In some
doors this will simply be impossible, preventing all users from
database access.
For those interested in dBASE-based on-line data base searches with
RBBS-PC, you might try writing Steven Kling at 4009 Utah Ave., Brentwood,
MD 20722. Steven is the author of BBS_BASE, USER_BASE and DoorBase.
BBS_BASE is a non-ANSI dBASE III demonstration DOOR that maintains a
database of Bulletin Board names, phone numbers, etc. This database can be
queried, added to, edited, and up to the minute reports can be generated.
The entire database with indices can be downloaded by the user for personal
use. This database is indexed and therefore can be queried either by name
or phone number. BBS_BASE was written only as a demonstration of using
RBBS-PC to access a data base remotely. USERBASE is a dBASE registration
door for RBBS-PC 15.1C and above. It comes in both ANSI and non-ANSI
versions and gives an automatic access upgrade capability to the SysOp at
his/her option.
Steven Kling and Michael Kelly are collaborating on DoorBase, which has
just been released, and this will give a SysOp the capability to place any
dBASE III database on-line, and will allow him/her to set up all the full
screen display features to his/her own specification. DoorBase has
multiple demonstration databases available including databases of
Congressmen, dBASE vendor support companies, and a national BBS listing.
Steven is also the SysOp of Technopeasants' EAST RBBS at (301)-927-4258
Brentwood, MD (PC Pursuitable) 24 Hours/ 2400 baud.
APPENDIX R -- Using RBBS-PC to access ORACLE or dBASE Remotely R-3
Michael is the SysOp of Technopeasants' WEST RBBS at (503)-257-7070
Portland, OR (PC Pursuitable) 24 Hours/ 2400 Baud.
Using ORACLE with RBBS-PC for On-line Data Base Access
------------------------------------------------------
Another database package that is able to be used as a "door" is ORACLE from
Oracle Corporation at One Oracle Parkway in Belmont, California 94002.
Their number is (800) 345-DBMS. ORACLE is a very promising solution to
providing remote data base services. Oracle addresses the problems
mentioned earlier as follows.
1) Screen writes. ORACLE can use ANSI sequences or bios calls. All
output appears perfectly normal on remote terminals through the CTTY
interface in RBBS-PC.
2) Monitor for carrier. Run WATCHDOG, which will reboot your system if
carrier drops.
3) Full screen mode. ORACLE uses only ANSI commands to control the users
screens. Callers whose remote communications package implements ANSI
support therefore see full screen writes exactly the same as local
users. FULL SCREEN WORKS!
4) Security. ORACLE has all the security you could ever want because it
was designed for multi-user systems.
5) Usability. ORACLE implements SQL, which is increasingly becoming an
industry standard that all major data base systems are supporting.
Of course, there are some problems using ORACLE in a way in which it was
never designed:
1) There is a problem getting the function keys to work properly
remotely.
2) The ability for a caller to use DOS commands needs to be disabled
within ORACLE.
3) Callers who do not know SQL need pre-structured queries and a menu
interface to be designed for them. ORACLE supports a full screen
interface but the user interface in ORACLE is not as programmable as
one would like.
For those interested in ORACLE-based on-line data base searches with
RBBS-PC, you might try writing John Prior at P.O. Box 56589, Harwood
Heights, IL 60656-0589. John is the SysOp of
SQLBBS at (312)-589-0508
Chicago, IL. (PC Pursuitable)
24 Hours/ 9600 baud Microcom MNP Level 6
The SQLBBS is a bulletin board system specializing in supporting relational
data base managers and making the power of SQL available to callers.
SQLBBS uses an RBBS-PC door to get into ORACLE. The SQLBBS has implemented
ORACLE to help manage the data processing for the National Council for
Children's Rights (NCCR), and has several major data bases on-line of
general interest. People can contact John Prior, the SQLBBS SysOp, on
Compuserve, by mail, or by calling SQLBBS if they wish to see how ORACLE is
implemented, get the latest progress report, or share experiences
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL R-4
implementing relational systems. Here are details on the SQLBBS system and
how to reach it:
Modem: 9600 Baud Microcom MNP Level 6
BBS Number: 312/589-0508
Hours: 24 hrs/day
Address: Prior Computer Service Inc.
POB 56589
Chicago IL 60656-0589
Compuserve ID: 76266,1072
SysOps: John F. Prior
Bernadette Foley
SQL Tables Roster of the House of Representatives
Available Roster of the Senate [both with addresses etc.]
Now The States [2 char abbreviation and full name]
All the 5 digit zip codes in the US
Call SQLBBS as you would any other RBBS-PC system. Go through the Door.
SQLBBS executes a "SELECT * FROM TAB;" for you which shows you the 50+
tables you can access. At the SQL> prompt execute any SELECT command you
want against any one of the tables.
"SELECT * FROM STATES;" returns all rows [records]
of the STATES table.
"SELECT * FROM STATES WHERE ST = 'MA';" returns all rows about the
state whose two-character
code is "MA".
"SELECT COUNT(*) FROM STATES;" gives you a count of the rows
in the STATES table.
If you substitute another table or view instead of STATES such as SENATE,
you can access other tables/views.
"DESC HOUSE" would return the column names of the HOUSE
table.
"HELP" gets you help.
"HELP SELECT" gets you help on the SELECT command.
"HELP SET" gets you help on the SET command
which can control many options for
display
"SHOW ALL" shows you everything you can SET.
"EXIT" terminates UFI and returns you to
RBBS-PC.
APPENDIX S -- Using RBBS-PC with SEAdog to Access FIDO-NET S-1
APPENDIX S -- Using RBBS-PC with SEAdog to Access FIDO-NET
----------------------------------------------------------
SEAdog is a full-featured electronic mail system based on the personal
computer and using standard telephone lines. It is a sophisticated store-
and-forward mail system which can be configured in a virtually unlimited
number of network topologies (more on this later). Unlike some network
systems, the end user need never concern himself with network routing -- it
all happens automatically. The user just submits and retrieves messages,
the system takes care of the details. The hardware needed to run RBBS-PC
is sufficient to run SEADOG.
SEAdog uses the FidoNet Electronic Mail Protocol, as defined in the
document, A Basic FidoNet Technical Standard, published by the
International FidoNet Association (IFNA). The FidoNet Protocol is a public
domain electronic mail standard originally developed by Tom Jennings for
the Fido bulletin board system. For more information about the FidoNet
Protocol, please write to:
The International FidoNet Association
P.O. Box 41143
St. Louis, Missouri 63141
United States of America
There are several advantages to using the FidoNet Protocol, not the least
of which is that a great many utilities and programs are available from
many different vendors for doing various things with electronic mail.
Please contact IFNA at the above address for more information.
The heart of SEAdog is the network mail server, MAILER.EXE. This is the
program that places and receives phone calls, handles message routing, and
so forth. It is left running when you would normally turn your machine
off.
You can set RBBS-PC to drop to DOS at a time when telephone costs are
cheapest (normally 4 a.m. Eastern Standard time and 1 a.m. Pacific time)
and invoke the mailer so that it begins placing phone calls to other SEAdog
systems to pass them your outgoing mail and receive your incoming mail.
SEAdog costs $100.00 and can be ordered from the address or phone number
below.
Thom Henderson
SYSTEM ENCHANCEMENT ASSOCIATES
21 Wayne Street
Wayne, New Jersey 07470
V:201-473-5153
This doc file is not intended to replace the SEAdog manual, but rather
provide information that an RBBS-PC SysOp would find useful when
configuring RBBS-PC to run with SEAdog.
The current status of the RBBS-PC - SEAdog project is at the level in which
RBBS-PC has the ability to be front-ended by SEAdog in where SEAdog will
turn over to it a live, active modem with a caller waiting. RBBS-PC has
been modified to accept two additional command line parameters which can
alter the defaults in RBBS-PC.DEF. Currently, that is the extent to which
RBBS-PC and SEAdog can be used together. The Fido message base format is
not yet compatible with RBBS-PC.
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL S-2
It is assumed that you are reading this because you are familiar with the
RBBS-PC and have at least a minimum knowledge of FidoNet and FidoMail.
Another assumption is that you have RBBS-PC up and running on your
computer. The easiest way to get all two programs working together is to
have each running from it's own subdirectory on your hard disk. That'll
make maintenance of RBBS-PC and SEAdog specific files much easier. Follow
the instructions in the SEAdog manual to install it, if that hasn't been
done yet. Once installed all SEAdog files will be in a subdirectory called
\MAIL. Make any required modifications to your CONFIG.SYS as suggested in
the SEAdog manual.
If your using DOS 3.xx, and don't use the DOS SUBST command, you should
consider doing so. SUBST is a DOS external command that allows you to
SUBSTitute a drive letter for a complete subdirectory name. Using this
command will make reprogramming RBBS-PC's configuration file easier.
This appendix assumes that all the SEAdog Files are in a subdirectory
called C:\MAIL and those for RBBS-PC are in a directory called C:\RBBS.
A further assumption that is made is that a new drive "H:" will be
SUBSTitued for the C:\RBBS subdirectory.
Since SEAdog will be in controls most of the time, the entire operation
should use SEAdog's C:\MAIL directory as the default.
Now load and run CONFIG.EXE and reprogram it's configuration to reflect
that all RBBS's help, menu and system files are located on the "H:" drive.
Remember the SUBSTitute command? You can use it to replace those long
subdirectory names for download and upload files. SPECIAL ATTENTION must
be paid to CONFIG.EXE's parameter 163. This parameter MUST be set to SYSTEM
recycle. Not doing so will cause RBBS-PC to reload itself after a caller
has hung up or dropped carrier and not pass control back to SEAdog.
The SEAdog manual explains various commands that must be placed in it's
configuration file called CONFIG.DOG. Among those that are considered a
minimum, you should include at least the following....
banner Please stby, 15 secs to load RBBS-PC
bbs H:RBBS *T *B
event B all 4:30 5:00 ;Local collections
event A all 5:00 6:00 ;National FidoMail Window
event C all 6:00 7:00 ;Local distributions
event S all 7:00 4:00 Crash Dynamic BBS ;CRASH mail if not in RBBS
event X10 all 7:00 7:05 ;Reboot Computer
The banner statement should be used so that human callers know why there
is a delay from the time they connect until the time they see RBBS-PC
display it's welcome message. The bbs command tells SEAdog what batch
file to run when passing control to RBBS. *T and *B must be in the order
presented above in for RBBS-PC to pickup and use them correctly. They pass
the time remaining to the next scheduled SEAdog event and the baud rate the
caller came on with. Event statements tell SEAdog how to schedule it's
time during the day. The above example conforms to the FidoNet national
mails hours as of 26 July 1987 and allows crash mail and bbs operation at
all others.
Since the SEAdog *P parameter in the bbs command isn't used, you must
insure that the comm ports used for RBBS-PC and SEAdog are the same.
APPENDIX S -- Using RBBS-PC with SEAdog to Access FIDO-NET S-3
One of the more confusing decisions will be how to setup the modem
switches. Without going into it too deeply, keep in mind that SEAdog will
be controlling the modem and passing an active modem on to RBBS-PC.
Additionally, you could have your SEAdog upload and download areas overlap
those of RBBS-PC.
When SEAdog determines that a non SEAdog or Fido system has called, it runs
a second copy of DOS, then optionally loads and runs RBBS-PC via direct
command or from a batch file, passing the speed that the comm port was
opened at, and the time remaining to the next scheduled SEAdog mailer event
as in the following example:
SEAdog calls RBBS-PC via a batch file called RBBS.BAT
C>RBBS-PC 1 H:RBBS-PC.DEF /%1 /%2
| | | | |> Baud Rate
| | | |
| | | |
| | | |> Limits the amount of time the user has
| | | this session if and only if the time is
| | |less then the time per session specified |||in CONFIG.EXE.
| | |> RBBS-PC default file filespec (Optional)
| |> Node number that the specified .DEF file applies to.
| |(Optional)
|> The name of the RBBS-PC program.
With a properly configured RBBS.BAT batch file, you can retain all the
functions of RBBS-PC to include DOORS and dropping to DOS via SysOp
function #7. See the sample batch files at the end of this file.
Experience has shown that the best way to run RBBS-PC and SEAdog is with a
batch file, where SEAdog having determined that a non mailer system is
waiting to use the bbs will load and run a batch file that controls RBBS-
PC's operation as opposed to SEAdog calling RBBS-PC directly. Two batch
files are used, one to control SEAdog and one to control RBBS.
A minimum batch file is suggested in the SEAdog manual. In addition to what
ever you place in it, add the following statements to it.
If Exist H:RCTTY.BAT Del H:RCTTY.BAT
This line should be the first. This statement simply helps ensure proper
operation of RBBS-PC if you use SysOp function #7 or DOORS.
If Errorlevel 10 Goto REBOOT:
This line goes after the line that contains the call to the MAILER program.
REBOOT:
IPL
This line reboots the computer every morning according to event listed
above. Due do unexplained loss of memory when running SEAdog and RBBS-PC,
is safe to program in a scheduled rebooting of the computer to regain any
loss of memory. This line should be near the last and programmed around for
normal operations
** Ex RBBS batch file **
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL S-4
Echo Off
:LOOP
C:
Cd \MAIL
If Not Exist H:RCTTY.BAT Goto LOCAL
H:WATCHDG1 OFF
Del H:RCTTY.BAT
H:TESTRBBS 1 H:RBBS-PC.DEF
Goto REMOTE
:LOCAL
H:TESTRBBS 1 H:RBBS-PC.DEF /%1 /%2
:REMOTE
If Not Exist H:RCTTY.BAT GOTO EXIT
H:WATCHDG1 ON
H:RCTTY.BAT
:EXIT
As mentioned above, this doc file isn't intended to make you completely
knowledgeable on how to interface RBBS-PC and SEAdog, only get you started.
How you set up your RBBS-PC and SEAdog batch files is limited only by your
ability and imagination. After gaining more experience, you'll find that
you can automate a lot of the RBBS-PC and SEAdog maintenance.
The above reflects the creative things that Kim Wells, Fido Address
109/652, has done with interfacing RBBS-PC with the Fido net-mail system.
If you need further help, contact Kim Wells's RBBS-PC via his data line at
(301) 599-7651/7652.
APPENDIX T -- DOS Limitation on Running Programs Remotely T-1
APPENDIX T -- DOS Limitation on Running Programs Remotely
---------------------------------------------------------
When accessing your PC via a communications port, the carrier detect signal
tells the PC that you are on-line. DOS's major limitation is that there is
no way to tell DOS to monitor carrier detect automatically when the
standard input and output is transferred to a communication port (i.e. via
the CTTY command). RBBS-PC makes sure that the carrier is not dropped
when a user exits to DOS either via the "DOORS" option or using the remote
SysOp function 7. However, it is the SysOp's responsibility to insure
that whatever programs are invoked after leaving RBBS-PC perform all
the necessary functions to maintain the communications session and, when
exiting to return to RBBS-PC, that the carrier is "NOT" dropped.
Most application programs (i.e. databases, etc.) are not designed to be
controlled by users accessing them from a communications port. This
problem is solved when a function is invoked that:
1. Checks to see if the standard input and output console have been
assigned to an auxiliary console such as a communication port.
2. If condition 1 is true, checks to see if the carrier detect signal is
lost by intercepting each interrupt from the communication port the
auxiliary console has been assigned to.
3. If BOTH conditions 1 and 2 are true, this function would cause DOS to
return to the standard screen and keyboard for its operations AND continue
processing whatever batch file that had been executing.
Such a function (or device driver) would provide a "fail safe" feature that
would allow users to exit RBBS-PC to use whatever other software the
SysOp chose to make available (i.e. relational databases for complex
inquiries -- bibliographic, sports, games, etc.). For those
anticipating using RBBS-PC's "doors" or exiting to DOS when you are a
remote SysOp, you are strongly encouraged to consider using the "watchdog"
utility program available on many bulletin board systems under such file
names as WATCHDOG.COM, WATCHDOG.ASM, WATCHDOG.DOC, WATCHDOG.EXE that
monitors the communication port for you and reboots your system if carrier
drops. If you don't use a program like WATCHDOG and accidentally hang up
while in a "door" or in DOS, you system will remain "hung" until you can
manually reboot it.
Programs that utilize the PC's built in video memory (such as the IBM BASIC
interpreter or WordStar when it writes to the 25th line) need to have such
I/O redirected in a special way to a remote users terminal. Additionally,
if the I/O is redirected to the communications port, the terminal on the
other end must have a "cursor" that can be sent the appropriate command
sequence to move it around on the remote users terminal as necessary.
Without this capability, programs made available through "doors" must be
line-at-a-time programs. This of course excludes programs such as
WordStar, Lotus/123 etc.
If you aren't technically inclined and want to use RBBS-PC "doors", I
suggest you consider only using programs that have been explicitly written
to overcome the above two DOS limitations. Applications that don't write
directly to the video memory of the PC can be used safely as a "door" as
long as a "watchdog" type program is also used.
APPENDIX U -- Recompiling RBBS-PC to Reduce Memory Required U-1
APPENDIX U -- Recompiling RBBS-PC to Reduce Memory Required
-----------------------------------------------------------
RBBS-PC is continually being enhanced with new features. As new functions
and capabilities are added, RBBS-PC's memory requirements grow
correspondingly. In order to continue RBBS-PC's growth and still meet the
memory constraints imposed on SysOps with only 640K of memory who wish to
run two copies of RBBS-PC, RBBS-PC source code can be "mite-sized" and
recompiled to fit within whatever memory constraints a SysOp must deal
with.
SysOps can apply .MRG files against the unmodified RBBS-PC source code and
elect to eliminate RBBS-PC features not being used and eliminate redundant
code (typically the BASIC source code that replicates assembly language
routines). RBBS-PC has a companion "mite-size" set of files contained in
the file RBBS-LIT.ZIP.
In order to recompile and "mite-size" RBBS-PC, within the same environment
in which the SysOp has successfully recompiled the current release of RBBS-
PC, the SysOp must also have the following files:
BLED.EXE -- The Batch Line EDitor by Ken Goosens (version 2.2 or
greater).
MAKELIT.BAT -- The BATch file that invokes BLED.EXE and applies the
necessary files to the unmodified source code. This
file should be modified by putting in the drive/path
for the original code (the first parm to BLED). The
lines to be modified all begin with "*$", which is the
default for a BLED metacommand. The lines beginning
with "* " are BLED comments, which are ignored in a
merge.
SETLIT.INC -- The file through which the SysOp selects the RBBS-PC
features that are not needed. The directions for doing
this are contained within this file. A feature is
typically removed by setting a BLED metacommand
variable to "OFF", e.g. BAUD450 to "OFF" to save code
by excluding the RBBS-PC feature that allows 300 baud
uses to increase their baud rate to 450 while on-line.
To exclude RBBS-PC LIBRARY subsystem set LIBRARY to
"OFF".
RBBSLIT.MRG -- The fundamental BLED merge for RBBS-PC.BAS
SUBxLIT.MRG -- The fundamental BLED merge for various RBBSSUB's. Each
reads in (includes) the file SETLIT.INC to set the
metavariables used by BLED. BLED then uses the values
to determines what merges to process.
*.LIT -- .MRG files that eliminate RBBS-PC features.
The procedure for "mite-size"ing RBBS-PC is as follows:
1. Select the RBBS-PC features not required for your needs and modify the
file SETLIT.INC.
2. Change MAKELIT.BAT to reflect your PC's subdirectories.
3. Make sure RBBSSUB1.BAS is in the subdirectory you will run in.
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL U-2
4. Execute the MAKELIT.BAT file. Do not continue if errors are found.
5. Recompile the "mite-sized" RBBS-PC source code. Remember, this "mite-
sized" source code and the RBBS-PC.EXE file created from it my only be used
by you and not distributed to others.
Some comments on the various Microsoft QuickBASIC compilers:
QuickBASIC Version 1.02 produces the smallest code.
QuickBASIC Version 2.01 produces the next smallest code.
QuickBASIC Version 3.00 produces the largest code.
QuickBASIC Version 4.5 produces code smaller than
3.00) but is not as reliable
Never LINK with the /E option.
6. Re-run CONFIG and disable the RBBS-PC features that were deleted in the
"mite-sized" version that was created in steps 1 through 5 (i.e. take out
the "A" command if questionnaires were disabled).
Please realize that there is no way that the "mite-sized" variations of
RBBS-PC can be supported. The many different PC configurations plus the
multitude of combinations of RBBS-PC features are what make this
impossible. However, we will do our best.
Please report any problems with BLED or the *.LIT merges to Ken Goosens via
his RBBS-PC data number -- (703) 978-6360.
INDEX
.MRG 1-4 NEWUSER file 6-9, 10-9
99.DIR 6-5 NODE?WRK 6-5
ANSI 7-25 NODE?WRK file 7-27
ANSI commands 7-21 PASSWRDS file 6-9, 9-2, 10-15
ARCWORK?.DEF 6-4 PRELOG file 6-9, 10-11
ASCII upload 10-26 PRIV.DEF 6-9, 10-15
AUTOEXEC.BAT 13-1 PROTO.DEF 6-3, 10-24, 20-1
AUTOPAGE.DEF 6-6, 7-26, 10-3 PUI 7-4
BLED 1-4 use of color in 7-24
BULLET file 6-6 QMXFER.ERR 6-5
Bulletins Questionnaires 6-2, 10-9, 19-1
BULLET.FCK 6-4 RBBS.BAT 10-12, 13-1
CALLERS file 6-4, 10-11 RBBS?F1.DEF 6-5
Colorization 7-24 RBBS?PC.DEF 6-5
COMMENTS file 6-4, 10-11 RBBS-CDR.DEF 6-9
CONFENCE file 6-6, 10-9 RBBS-Net 4-1
CONFMAIL.DEF 6-7, 10-12 RBBS-PC in a Box 4-1
CPCUG 1-1 RBBS-REG.DEF 6-9, 10-11
DIR.CAT 10-22 RECONFIG.EXE 2-7
DIR.CDR 6-7 RelayNet 4-1
DIR.DIR 6-7 Ring-Back 10-23, E-1
DK*.ARC 6-5 SECVIO.HLP 10-16
DOORS.DEF 6-5, 10-13, 14-4 SHARE.EXE P-1
DORINFO?.DEF 6-5 SmartText 7-21
DOUT?.DEF 6-5 Subscriptions 9-1, 10-6
DRST?.DEF 6-5 SysOp 1-1
DTR 10-24 TDD 10-23, 10-26, E-1
EPILOG.DEF 6-7, 7-29, 10-11 templates 20-4
FFS 10-26 in DOORs 14-4
File Locking 6-1 TRASHCAN file 6-9, 10-10
FILESEC file 6-7, 10-15 USERS file 6-4, 10-11, 10-18
Flow control Userware 1-1
CTS 10-25 Version numbers 1-4
RTS 10-25 WELCOME file 6-9, 10-9
XON/XOFF 10-25 ZIPTV 7-28
FMS 10-21
use of color in 7-25
Graphics 6-6
HELP files 6-7
FILE.HLP 6-8
HELP03 6-7
HELP04 6-7
HELP09 6-7
LIBR.HLP 6-8
MAIN.HLP 6-8
RGXPIRD.HLP 6-8, 9-1, 10-6
RGXPIRE.HLP 6-8, 9-1, 10-6
SECVIO.HLP 6-8
SMARTTXT.HLP 6-8
UPCAT.HLP 6-8, 10-9
UTIL.HLP 6-8
LG*.DEF 6-8
Library Sub-System 6-7
MAIN.PUI 6-9, 10-9
MAINM.DEF 6-3
MAINU.DEF 6-4
MENU files 6-9, 7-1, 10-9
MESSAGES file 6-3, 10-11, 10-18
NETBIOS P-1
================= END OF RBBS-PC 17.3A DOCUMENTATION ==================